From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21431 invoked from network); 31 Mar 1999 07:17:51 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 31 Mar 1999 07:17:51 -0000 Received: (qmail 17151 invoked by alias); 31 Mar 1999 07:16:17 -0000 Mailing-List: contact zsh-users-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 2260 Received: (qmail 17144 invoked from network); 31 Mar 1999 07:16:09 -0000 From: "Bart Schaefer" Message-Id: <990330231453.ZM22023@candle.brasslantern.com> Date: Tue, 30 Mar 1999 23:14:53 -0800 In-Reply-To: <19990328231428.A11812@astaroth.nit.gwu.edu> 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> X-Mailer: Z-Mail (4.0b.820 20aug96) To: zsh-users@sunsite.auc.dk Subject: Re: zsh startup files MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Mar 28, 11:14pm, Sweth Chandramouli wrote: } Subject: Re: zsh startup files } } [...] in pretty much every other programming environment that i } can think of (and, when you get down to it, the shell _is_ just a } programming environment), you are guaranteed that, although there } might be system-wide defaults and settings, once the user is given } control of his/her environment, any changes he/she makes won't } subsequently be clobbered by the system [...] A shell isn't really a programming environment. People use shells all the time for things that aren't even remotely related to programming. 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. Of course, by that example, perhaps we DO need to encourage sysadmins to _properly_ install /etc/z*, by providing same (not the current examples) with instructions as to what properly goes (or does not) in each. Emacs is saved from insanity by delivering its runtime system pre-packaged. } the example bart gave of term settings in /etc/zprofile doesn't really } parse, for this very reason--the only reasonable times that the } interleaving will make term settings work instead of breaking them are } those when the system init files _won't_ work unless the user init } files make certain changes. You're at least partly right about that, although "won't work" is less often the case than "work but leave annoying glitches." Examples from my own experience include "benign" mislabelings of the terminal like vt100 when it should be vt220, or (one I'm currently wrangling with) correctly choosing "xterm" but having significantly different versions of X on the display server than on the login server, such that reverse video doesn't go on/off properly using the login server's terminfo. } [...] if NO_RCS were relevant anywhere in the init process, } [...] that seems of less value to me, however, than } being able to create init files that don't have to be carefully rechecked } every time the "other person" (the admin if you are a user, or the user if } you are an admin) makes a change. Unless your personal init files do _all_ necessary setup, as if /etc/z* were empty, you're going to have to recheck them in any case. And if you do completely supercede the system files, then having the system files sourced at all is, at best, a waste of time. } the best-of-both-worlds solution, i guess, would be [exceptionally baroque suggestion deleted] Any system which attempted to provide that level of control is (1) even harder to use than the corresponding `if [[ -o ... ]]; then ... fi` and (2) an open invitation to a sysadmin to use /etc/zshenv to set the order to what he likes and then typeset the corresponding variables read-only. The result is even less portable/predictable than before! On Mar 29, 9:15am, Stefan Monnier wrote: } Subject: Re: zsh startup files } } > 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 settings that might depend on } TERM/LINES/COLUMNS? 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). 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 administrator might be as likely to put the other two in /etc/zshrc as I was to put them in .zshrc, so if I can jump in at .zshenv or .zprofile and make sure the terminal setup is OK, I'm happier. 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). } 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*). 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. Boy, would it have been simpler for all concerned if csh had always read an /etc/csh.login back then. (And guess what tcsh does now? And guess in what order WRT the user's .cshrc?) -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com