From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9902 invoked from network); 18 Jul 2000 15:40:30 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 18 Jul 2000 15:40:30 -0000 Received: (qmail 26486 invoked by alias); 18 Jul 2000 15:40:19 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12300 Received: (qmail 26479 invoked from network); 18 Jul 2000 15:40:19 -0000 To: zsh-workers@sunsite.auc.dk From: zefram@fysh.org Subject: Re: PATCH: Re: adding a toplevel zsh.spec.in file Message-Id: Date: Tue, 18 Jul 2000 16:40:31 +0100 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