From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28422 invoked from network); 2 Apr 1999 13:13:51 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 2 Apr 1999 13:13:51 -0000 Received: (qmail 26503 invoked by alias); 2 Apr 1999 13:13:23 -0000 Mailing-List: contact zsh-users-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 2282 Received: (qmail 26496 invoked from network); 2 Apr 1999 13:13:22 -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: <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> <19990328231428.A11812@astaroth.nit.gwu.edu> <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> <5ln20wgz57.fsf@tequila.cs.yale.edu> <002501be79f0$86c54620$21c9ca95@mowp.siemens.ru> <990330231453.ZM22023@candle.brasslantern.com> Date: 02 Apr 1999 08:12:59 -0500 Message-ID: <5laewrtbc3.fsf@tequila.cs.yale.edu> X-Newsreader: Gnus v5.7/Emacs 20.3 Path: tequila.cs.yale.edu NNTP-Posting-Host: tequila.cs.yale.edu X-Trace: 2 Apr 1999 08:13:01 -0500, tequila.cs.yale.edu >>>>> "Bart" == Bart Schaefer writes: > If you want an example of an even more convoluted initialization system > that even more people use even more heavily than zsh, I need only point > you to emacs. I beg to disagree. Emacs's initialization is quite a bit simpler: site-lisp/site-start.el ~/.emacs site-lisp/default.el three simple steps where the last one can be disabled in either of the first two. > Sure. One, I set up the $LESS environment in zshrc, with z$[LINES-2] (set > scroll height to two less than $LINES). Two, I used to have a multi-line > $PS1, which I also set in zshrc, that depended on $COLUMNS, and that was > not used at all when the terminal was "emacs" or "dumb". Three, I played > for a while with different .exrc files for fast and slow connections; I > set up $EXINIT based on the terminal type (yes, that's what $BAUD is for, > but it was wrong for other reasons, and passing extra data through rlogin > by stuffing it into $TERM and then parsing it out again is a time-honored > hack). All these go in zshrc because they're useless to non-interactive > shells, but sometimes necessary even in non-login ones (think "su" if > nothing else). These sound like ad-hoc hacks that more or less work in some specific cases. Very far from the kind of things you'd want to put in /etc/zshrc. > The interleaving of init files let me get away with that last one, because > I could demangle $TERM in my .zshenv before /etc/zprofile ran. A system The $TERM mangling is an interesting case. I'd tend to say that if a /etc/zprofile or /etc/zshenv doesn't work with such a thing, it's broken. It might work suboptimally, tho. > Of course at this point (cf. the "exec" trick) I'm more likely to want to > bypass the system files entirely, but that wasn't always the case, and > sometimes isn't worth bothering with (I was just at a consulting job > where the /etc/z* files did extensive environment setup for a collection > of homegrown custom build tools; it would have been silly to try to redo > it or reorder it). So you agree in a sense: this fancy ordering is sometimes useful, but when it is, other alternatives would work as well. > Back when I was at OGI, the login banner had to announce that any user > whose .login was found _not_ to contain a certain set of commands, would > lose their access to the system. I'm all for a /etc/zshenv or maybe even more init files (as a sysadmin I really like to setup some envvars in there), but that has no relation to whether these should be sourced in such an interleaved manner. Stefan