From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6559 invoked from network); 28 Mar 1999 22:25:41 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 28 Mar 1999 22:25:41 -0000 Received: (qmail 1169 invoked by alias); 28 Mar 1999 22:24:50 -0000 Mailing-List: contact zsh-users-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 2249 Received: (qmail 1160 invoked from network); 28 Mar 1999 22:24:49 -0000 To: zsh-users@sunsite.auc.dk Sender: monnier@tequila.cs.yale.edu From: Stefan Monnier Newsgroups: lists.zsh.users Subject: Re: zsh startup files References: <5l90cmijvs.fsf@tequila.cs.yale.edu> <19990324181547.A4700@astaroth.nit.gwu.edu> <5l7ls6iee4.fsf@tequila.cs.yale.edu> <199903250220.VAA12122@gypsy.cad.gatech.edu> <19990325005332.B5194@astaroth.nit.gwu.edu> <9903250903.AA30753@ibmth.df.unipi.it> <9903251002.AA18225@ibmth.df.unipi.it> <199903251055.LAA02436@sally.ifm.uni-kiel.de> <9903251117.AA09841@rouble.olsen.ch> <9903251122.AA14741@ibmth.df.unipi.it> <5l1zidiw46.fsf@tequila.cs.yale.edu> <9903251400.AA54287@ibmth.df.unipi.it> <5lyaklgy2w.fsf@tequila.cs.yale.edu> <990327170423.ZM3271@candle.brasslantern.com> Date: 28 Mar 1999 17:14:05 -0500 Message-ID: <5logldgt3m.fsf@tequila.cs.yale.edu> X-Newsreader: Gnus v5.5/Emacs 20.3 Path: tequila.cs.yale.edu NNTP-Posting-Host: tequila.cs.yale.edu X-Trace: 28 Mar 1999 17:14:06 -0500, tequila.cs.yale.edu >>>>> "Bart" == Bart Schaefer writes: > The problem with this is that, for example, settings in /etc/zshrc may > depend upon settings performed earlier. The idea behind interleaving the > user and system init files is so that, at each decision point in the > system administrator's initialization chain, the user gets a chance to > step in and change the details with his own initialization. Sounds nice in theory, but how about practice ? In my world, /etc/zshrc is normally designed to work in the environment setup by /etc/zshenv and /etc/zprofile and if people add things in their ~/.zshrnv or ~/.zprofile, two things can happen: either the change is orthogonal to the sysadmin's settings so there's no interaction, or there's some interaction and it then tendfs to break the subsequent /etc/zshrc (or the /etc/zshrc just undoes the~/.zprofile's settings). Could you give a (few) example(s) where the interleaving is beneficial ? > The order in which the files are sourced is designed to make it easy for > a user who wants to make *minimal* changes to the system-wide defaults. > If all I care about is changing one setting that's in /etc/zprofile, I It seems it just makes it easy to make changes that don't have the intended effect because other code is executed afterwards. > If the ordering is as you just proposed, then in order to fix that one > zprofile setting I may have to duplicate large sections of /etc/zshrc and > /etc/zlogin in my .zshrc and .zlogin (or source them again, which might > break in some other way). Again a (few) example(s) of when this might happen would come in handy. I never came across any such situation. > make it work. Many choices in the early days of zsh were made so that > it would be easy for a novice, even if that made it noticably harder for > an expert. Ignoring NO_RCS after /etc/zshenv doesn't seem to make anything easier for novices but does seem to make things much harder for the experienced user. > (3) Use "exec" in .zshenv or .zprofile as I described above. Note that this `exec' solution cannot be used for the case of commands executed from `rsh'. Stefan