From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 531 invoked from network); 31 May 1999 05:40:13 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 31 May 1999 05:40:13 -0000 Received: (qmail 21655 invoked by alias); 31 May 1999 05:39:55 -0000 Mailing-List: contact zsh-users-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 2351 Received: (qmail 21648 invoked from network); 31 May 1999 05:39:53 -0000 From: "Bart Schaefer" Message-Id: <990531053930.ZM1092@candle.brasslantern.com> Date: Mon, 31 May 1999 05:39:30 +0000 In-Reply-To: <9905231441.AA28756@ibmth.df.unipi.it> Comments: In reply to Peter Stephenson "Reading initialization/logout files again." (May 23, 4:41pm) References: <9905231441.AA28756@ibmth.df.unipi.it> X-Mailer: Z-Mail (5.0.0 30July97) To: Peter Stephenson , zsh-users@sunsite.auc.dk (Zsh users list) Subject: Re: Reading initialization/logout files again. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii (I feel a bit odd being the poster of ten consecutive zsh-workers article numbers and several more on zsh-users, but I'm still catching up after my system downtime.) On May 23, 4:41pm, Peter Stephenson wrote: } Subject: Reading initialization/logout files again. } } This was some discussion about this before. In fact, very far before. Start at http://www.zsh.org/cgi-bin/mla/redirect?WORKERNUMBER=488 (yes, four hundred eighty-eight) and work your way up the references links. } I'm not sure why NO_RCS behaves the way it does at the moment; it may be so } that the administrator can unset it in /etc/zshenv Also note that in the thread around zsh-workers/1414, Zoltan ignored me when I repeatedly asked why NO_RCS works the way it does. } The latest proposal to allow more flexibility as follows: } } - The NO_RCS option (or negated RCS option) remains as before } } - A new NO_GLOBAL_RCS [...] will determine whether the /etc/z* files are } sourced at any stage. } } - The previously proposed option GLOBAL_RCS_FIRST would be removed. } } There are alternatives, however: } } 1. [...] make the NO_RCS option more } flexible and allow it to determine the subsequent behaviour at any stage } } 2. [...] make NO_GLOBAL_RCS work just like NO_RCS, except that } it applies to files in /etc only and is tested just after .zshenv is run. All three of these suggestions (latest, #1, #2) are OK. I slightly prefer alternative #1, and slightly dislike alternative #2. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com