Re: zsh startup files

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

On Mar 28,  5:14pm, Stefan Monnier wrote:
} Subject: Re: zsh startup files
}
} >>>>> "Bart" == Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> writes:
} > The idea behind interleaving the user and system init files is
} > so that, at each decision point in the system administrator's
} > initialization chain, the user gets a chance to step in and change
} > the details with his own initialization.
} 
} Sounds nice in theory, but how about practice ?

Let me first point out that none of this is interesting for non-interactive
shells.  So when you later say:

} > (3) Use "exec" in .zshenv or .zprofile as I described above.
} 
} Note that this `exec' solution cannot be used for the case of commands
} executed from `rsh'.

I say, so what?  Only the two zshenv files are being sourced in that case
anyway.

} 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.

I could come up with other examples, but they'd all be of that same shape.
Yes, in some cases it might be necessary to set your $path in .zshenv and
then set it again in .zlogin, or whatever.  The point is that if you care
about what happens in between in /etc/z*, rather than simply wanting to
skip it entirely and do only your own stuff, then you need to get your
shot at it both before and after.

} It seems it just makes it easy to make changes that don't have the intended
} effect because other code is executed afterwards.
} 
} Ignoring NO_RCS after /etc/zshenv doesn't seem to make anything easier for
} novices but does seem to make things much harder for the experienced user.

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.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com