From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 286 invoked from network); 23 May 1999 15:09:38 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 23 May 1999 15:09:38 -0000 Received: (qmail 662 invoked by alias); 23 May 1999 15:09:18 -0000 Mailing-List: contact zsh-users-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 2343 Received: (qmail 650 invoked from network); 23 May 1999 15:09:17 -0000 Message-Id: <9905231441.AA28756@ibmth.df.unipi.it> To: zsh-users@sunsite.auc.dk (Zsh users list) Subject: Reading initialization/logout files again. Date: Sun, 23 May 1999 16:41:45 +0200 From: Peter Stephenson This was some discussion about this before. The latest proposal to allow more flexibility as follows: - The NO_RCS option (or negated RCS option) remains as before, i.e. it only takes affect for initialisation files if set as a starting option to the shell or in /etc/zshenv, but if set on logout it disables sourcing /etc/zlogout and .zlogout too. - A new NO_GLOBAL_RCS option. For greater flexibility, you could set or unset this anywhere and it will determine whether the /etc/z* files are sourced at any stage. As before, /etc/zshenv is always sourced since there are legitimate reasons for this (as well as illegitimate ones). - The previously proposed option GLOBAL_RCS_FIRST would be removed. There are alternatives, however: 1. it's not well documented that setting NO_RCS prevents running /etc/zlogout and .zlogout. So if no-one was setting it in their .z* files for this purpose, it would be possible to make the NO_RCS option more flexible and allow it to determine the subsequent behaviour at any stage, as NO_GLOBAL_RCS would do. But if people are (say) setting it in .zprofile in the knowledge that it doesn't take effect until logout this will cause problems, and anyone who is should say so now. Currently, altering it for other reasons in .zshenv/.zprofile/.zshrc/.zlogin doesn't have any effect, so we probably don't need to worry about that happening. This is the cleanest option. 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 and so enforce the rest of the scripts, but it should be quite enough having one file that is always run. 2. for consistency, if people didn't really care about greater control, it would be possible to 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. It's not that consistent, though; as the idea is to let the user get their hands on it, it has to be tested later than NO_RCS anyway. -- Peter Stephenson Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy