Re: PATCH: Re: adding a toplevel zsh.spec.in file

[zefram@xxxxxxxx]

Bart Schaefer wrote:
>Besides, sourcing /etc/profile effectively prevents a sysadmin from having
>any zsh-specific code in the global startups.  I think that's going to have
>the exact opposite effect from what you want -- it's going to encourage
>admins to build zsh with the global RC files *enabled*, so that they can
>separate the zsh-specific stuff.

/etc/profile is there to set up bits of the environment that pertain to
the local system.  It's an adjunct to login; it does the new mail check
on systems where login doesn't, it sets MAIL if login doesn't, and it can
set TAPE and stuff if that's really necessary on that system.  My point is
that the things that need to be done are the same regardless of what shell
the user prefers to use, and so there shouldn't be any zsh-specific stuff.

Andrej Borsenkow wrote:
>- wordsplitting :-) (yes, it may happen)
>- some /etc/profile(s) (ours at least) check the the value of $0 for
>being somehing like -sh and do not expect -zsh here.

Yes, I momentarily forgot that sh syntax is sufficiently different from
zsh syntax to make this problematic.  Obviously my scheme needs a little
rethinking.

>I use /etc/zprofile that defines function that sets shwordsplit, fakes
>$0 being -sh (hmm, may there be some security problems in case of su?)
>and sources /etc/profile.

Perhaps we can locally emulate sh when sourcing /etc/profile?  We have
the local emulation logic working for functions, and /etc/profile can't
possibly get confused by that, because it can't contain any setopt
commands.  The $0 issue remains.  What does $0 get examined for?

Hmm, the local emulation has lots of advantages.  It means that one
can simply install zsh on an existing system without having to worry
about global startup files.  There'll be no need to write a zsh-specific
/etc/zprofile.

Bart Schaefer wrote:
>However, I'm curious why you object to (e.g.) setting $PATH in /etc/zshenv.
>On systems where commands are installed in nonstandard places, why should
>every user's own .zshenv have to contain the settings that make rsh (and
>other noninteractive/nonlogin shells) find commands in the right places?

PATH (or anything else) shouldn't be set in /etc/zshenv because then it'd
be set for every shell that starts, whereas shells that are run explicitly
are supposed to inherit the environment from their parent process.
Obviously the user can affect that with .zshenv, but that's their choice;
/etc/zshenv would force these modified semantics on everyone.

/etc/profile is the proper place for local configuration, because then
it's done once, which is all that's desired.

rshd is defective in not providing a way to locally affect the environment
of a new shell that it creates.  Yet another reason to switch to ssh.
Being less flippant, if the user is going to rsh into somewhere, they
simply have to know about this problem and allow for it.  It's well
understood.

>} The only annoying thing left is that the global zprofile is run *after*
>} the user's .zshenv.
>
>Why is that annoying?

Whatever we run as our equivalent of /etc/profile might choose to set
the PATH and other bits of the environment.  The user should have the
possibility of overriding what's set up there, using their .zshenv.
As it is, a PATH setting in .zshenv can be stomped on by /etc/zprofile.

>I predict that every system that currently ships with non-empy /etc/z*
>files will simply compile with these configs enabled, and continue to
>ship non-empty /etc/z* files.  Obviously the maintainers of those
>environments believe that there's value in the settings they place in
>those files.

I think they haven't actually thought much about the issues we're
discussing.  If we ship with /etc/z* disabled by default, then they'll
*have* to think before they can ship non-empty effective /etc/z*.
We should make it non-trivial to do the thing that is almost always wrong.

Peter Stephenson wrote:
>                                            There are perfectly good, if
>specialised, reasons for adding stuff.

Yes.  My point is that the valid reasons are all very specialised
and unusual, so it doesn't seem too much of an imposition to ask that
the administrator handling this specialised situation also install a
specialised version of zsh.

>The way forward is to educate people over the use of startup script.
>They're willing to learn if you explain things to them.

Yes, the documentation should probably explain these issues, regardless
of what default behavior we decide upon.

-zefram