Re: zsh startup files

[Stefan Monnier <monnier+lists/zsh/users/news/@tequila.cs.yale.edu>]

>>>>> "Bart" == Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> 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