Re: zsh startup files

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

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