Re: zsh startup files

[Sweth Chandramouli <sweth@astaroth.nit.gwu.edu>]

On Sun, Mar 28, 1999 at 05:57:51PM -0800, Bart Schaefer wrote:
> } Could you give a (few) example(s) where the interleaving is beneficial ?
> 
> 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.
> 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.
	what this issue really gets down to is portability and ease of use;
the current interleaving of system and user init files makes the task of
writing init files much more complicated than it should be, and the task of
writing portable ones even more difficult.  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; in zsh, however, the interleaving
of init files means that at every stage of the init process, the user has
to be aware (and wary) of the system configurations--both their end effect,
which most programmers have to deal with, and the process by which that
effect is achieved, which most other environments don't require.
	the problems go both ways, for that matter--the sysadmin has no
way of being assured, with the current setup, that a user won't do something
in a user init file that will break all of the subsequent system init files.
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.

> 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.
	the question isn't whether or not the other code should run at all;
it's whether or not the other code should be able to, in running, change
the environment of the user midstream.

	the one way that interleaving the init files could be helpful, as far
as i can see, would be if NO_RCS were relevant anywhere in the init process,
as bart has suggested before--then, a user could halt the init process, say,
after the zlogin files (both system and user) had run, but before any of the
zshrc files were sourced.  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.
	the best-of-both-worlds solution, i guess, would be a solution that
let the user choose between either model, and which (for compatibility reasons)
defaulted to the current model (but which would eventually migrate to the
all-system-inits, then all-user-inits model).  the best way i can think of
to implement this would be to make five "special" arrays (ENV_INITS, 
LOGIN_INITS, RC_INITS, PROFILE_INITS, and LOGOUT_INITS) which by default (for
a login shell--non-login interactive shells and non-interactive shells, 
would have different values, obviously), the values of these arrays would be 
set to (/etc/zshenv ~/.zshenv), (/etc/zlogin ~/.zlogin), (/etc/zshrc ~/.zshrc),
(/etc/zprofile ~/.zprofile), and (/etc/zlogout ~/.zlogout).  then, i would
add an option (SEQUENTIAL_INITS) that defaults to a value of ON, and
which could be changed at any time.  at every "init file checkpoint" (defined
as the moment when init files would first be sourced normally, and then after
every init file is subsequently sourced), then, the value of SEQUENTIAL_INITS 
would be checked.  if it were ON, then the first value in the next special
array (proceeding through the arrays in the order listed above) would be 
"popped" out of the array, and the relevant file sourced; if the array in
question were empty, then the next array in order would be checked.  if 
SEQUENTIAL_INITS were OFF, however, then after "popping" the value off one
of the init arrays, the first value of the _next_ array would be popped,
wrapping around to the beginning once PROFILE_INIT was reached.  (LOGOUT_INIT
would not be part of either scenario, instead only being checked on logout,
obviously.)
	with this sort of solution, by default the current behaviour would
be maintained.  any user could, however, in their ~/.zshenv `unsetopt
SEQUENTIAL_INITS', and then reset the init arrays to just contain their
user init files; the only system init file that would be sourced in this
scenario, then, would be /etc/zshenv.  the NO_RCS option could then be
redefined to mean that all init arrays would be cleared if that option were
set in one of the files referenced in ENV_INITS, or just LOGOUT_INITS
would be cleared if that option were set anywhere else; this should duplicate
the current NO_RCS behaviour, while letting people like bart (and myself)
who would rather have NO_RCS take effect whenever it is set could just
change the values of the init arrays directly.

	this is just a quick off-the-cuff solution idea; i'm sure others can 
come up with good modifications.  (and someone would have to implement it, of 
course; i'm staring at my "practical c programming" book and wondering how
long it would take to get up to speed with c.)

	-- sweth.

-- 
Sweth Chandramouli
IS Coordinator, The George Washington University
<sweth@gwu.edu> / (202) 994 - 8521 (V) / (202) 994 - 0458 (F)
<a href="http://astaroth.nit.gwu.edu/~sweth/disc.html">*</a>