From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17692 invoked from network); 29 Mar 1999 14:17:35 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 29 Mar 1999 14:17:35 -0000 Received: (qmail 22224 invoked by alias); 29 Mar 1999 14:16:13 -0000 Mailing-List: contact zsh-users-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 2255 Received: (qmail 22217 invoked from network); 29 Mar 1999 14:16:11 -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> <5logldgt3m.fsf@tequila.cs.yale.edu> <990328175751.ZM8402@candle.brasslantern.com> Date: 29 Mar 1999 09:15:48 -0500 Message-ID: <5ln20wgz57.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: 29 Mar 1999 09:15:48 -0500, tequila.cs.yale.edu > } Note that this `exec' solution cannot be used for the case of commands > } executed from `rsh'. > I say, so what? Only the two zshenv files are being sourced in that case > anyway. Good point. > The canonical example of this being useful is terminal setup, which is > frequently done in /etc/profile on SVR4 systems (Motorola, Data General, > Olivetti, NCR, etc., where Bourne shell is often still the default shell) > and which a sysadmin is therefore likely to place in /etc/zprofile. [ passing note: if someone could tell me in which case terminal setup is useful, I'd be happy to learn. I've never needed any such thing. I thought it was because I only use xterm terminals, but now that I have a dumb-terminal plugged into my workstation, I have to revise this judgment. Maybe the terminal setup is only unnecessary for xterm and vt220-compatible (i.e. for vt100-style) terminals ? ] > Settings in zshrc and zlogin (whether /etc/ or ~/.) may depend on correct > values of TERM, LINES, and COLUMNS; it's too late to fix them after the > entire system initialization has run (without duplicating the parts that > rely on them), but too early to fix them before /etc/zprofile. Could you give examples of zshrc (zlogin is irrelevant to me: you either use zlogin or zprofile, not both) settings that might depend on TERM/LINES/COLUMNS? Also, if the sysadmin's files require changes in .zprofile for /etc/zshrc to work properly, it just means that /etc/zprofile (or /etc/zshrc) is somewhat bogus. It seems more likely that /etc/zshrc works properly when executed straight after /etc/zprofile and the .profile might break it. > about what happens in between in /etc/z*, rather than simply wanting to > skip it entirely and do only your own stuff, then you need to get your > shot at it both before and after. The /etc/z* files should be *minimal*. Anything that is not strictly necessary should be moved to /etc/user/foo and explicitly sourced from ~/.z* (themselves inherited from /etc/skel/.z*). This gives the user and the sysadmin much more freedom and flexibility than the default complex sequence. > I entirely agree that if what you want is for that other code to NOT run, > then the current startup file system is deficient. That's a different > issue from running the code in some other order. Actually, the ability to use NO_RCS is really all I need since I can then manually source the files I want in the order I want. The complex setup suggested by Sweth seems unwarranted and cumbersome. The only problem with NO_RCS is the logout files, so adding a variable holding the files to be executed at logout is all that's needed. Stefan