* Re: PATCH: Re: adding a toplevel zsh.spec.in file @ 2000-07-18 15:40 zefram 2000-07-18 16:37 ` Andrej Borsenkow 0 siblings, 1 reply; 12+ messages in thread From: zefram @ 2000-07-18 15:40 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: PATCH: Re: adding a toplevel zsh.spec.in file 2000-07-18 15:40 PATCH: Re: adding a toplevel zsh.spec.in file zefram @ 2000-07-18 16:37 ` Andrej Borsenkow 0 siblings, 0 replies; 12+ messages in thread From: Andrej Borsenkow @ 2000-07-18 16:37 UTC (permalink / raw) To: zefram, zsh-workers > > /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: > > 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? > Pretty much everything that you described above + output of /etc/motd, setting terminals parameter depending of terminal type (there are several standard ones that are normally shipped with systems) happens under case $0 in -sh|-ksh|-jsh|-rsh) Do not ask me why; I have not written it and have no chance to change it. Actually, since I'm running under X I do not care about /etc/profile anymore; it is sourced by Xsession so environment gets set up anyway (to account for optional software that may add something to /etc/profile) and I do not care about setting terminal under dtterm :-) So, unless this is an issue on more than one system, we can probably ignore it. But if we are going to locally emulate /bin/sh - why not pretend, we *are* -sh? :-) -andrej ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: adding a toplevel zsh.spec.in file
@ 2000-07-17 15:09 Adam Spiers
2000-07-18 1:56 ` PATCH: " Zefram
0 siblings, 1 reply; 12+ messages in thread
From: Adam Spiers @ 2000-07-17 15:09 UTC (permalink / raw)
To: zsh workers mailing list
Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
> On Jul 7, 6:44pm, Zefram wrote:
> } Subject: Re: adding a toplevel zsh.spec.in file
> }
> } Is there anything that ought to go in /etc/z* on more machines than,
> } say, those in a single company?
>
> I've always asserted that there is not, with the possible exception of
> default path settings in /etc/zshenv.
In /etc/zshenv:
What about setting of umask? In the last discussion about this kind
of stuff you suggested that umask setting was better done in zshrc.
But shouldn't it be set correctly for non-interactive processes too?
These don't do much harm either (quoted mostly straight from Bart
anyway ;-)
export USER=`id -un`
export LOGNAME=$USER
export HOSTNAME=$HOST
# this only on appropriate boxes of course
export MAIL=/var/spool/mail/$USER
HISTSIZE=1000
HISTFILE=~/.zshhistory
SAVEHIST=1000
export INPUTRC=/etc/inputrc
Is there any good reason why /sbin and /usr/sbin should not be on
every user's path by default? They're not under RedHat, which is
infuriating when it comes to using traceroute, lsof etc.
Now here's a candidate for StartupFiles/RedHat/zshrc. Anything badly
wrong?
--------- 8< --------- 8< --------- 8< --------- 8< --------- 8< ---------
#
# /etc/zshrc is sourced in interactive shells. It
# should contain commands to set up aliases, functions,
# options, key bindings, etc.
#
# Set up aliases
alias mv='nocorrect mv' # no spelling correction on mv
alias cp='nocorrect cp' # no spelling correction on cp
alias mkdir='nocorrect mkdir' # no spelling correction on mkdir
# Where to look for autoloaded function definitions
fpath=(
~/{lib/zsh,.zsh}/{functions,scripts}(N)
~/.z{sh,}func*(N)
$fpath
/usr/doc/zsh*/Functions(N)
)
typeset -U fpath
# Autoload all shell functions from all directories
# in $fpath that have the executable bit on
# (the executable bit is not necessary, but gives
# you an easy way to stop the autoloading of a
# particular shell function).
for dirname in $fpath
do
fns=( $dirname/*(N.x:t) )
(( $#fns )) && autoload $fns
done
# Set prompts
PS1='%n@%m %B%3~%b %# ' # default prompt
#RPS1=' %~' # prompt for right side of screen
#bindkey -v # vi key bindings
#bindkey -e # emacs key bindings
#bindkey ' ' magic-space # also do history expansion on space
--------- 8< --------- 8< --------- 8< --------- 8< --------- 8< ---------
^ permalink raw reply [flat|nested] 12+ messages in thread
* PATCH: Re: adding a toplevel zsh.spec.in file 2000-07-17 15:09 Adam Spiers @ 2000-07-18 1:56 ` Zefram 2000-07-18 5:22 ` Bart Schaefer ` (3 more replies) 0 siblings, 4 replies; 12+ messages in thread From: Zefram @ 2000-07-18 1:56 UTC (permalink / raw) To: Adam Spiers; +Cc: zsh workers mailing list Adam Spiers wrote: >In /etc/zshenv: > > export USER=`id -un` > export LOGNAME=$USER > export HOSTNAME=$HOST > > # this only on appropriate boxes of course > export MAIL=/var/spool/mail/$USER These, if they exist at all (which is OK if done right), should be in /etc/zprofile, and duplicated in /etc/profile. They should be set on *login*, not for every shell I start -- if I want to set MAIL to somewhere different, that setting should propagate to any subshells I run. > HISTSIZE=1000 > HISTFILE=~/.zshhistory > SAVEHIST=1000 No way. zsh has a perfectly well-established default behaviour w.r.t. history saving, and if I don't override it I should get zsh's default, not whatever some RPM builder thought might be nice. > export INPUTRC=/etc/inputrc My environment is my own. /etc{z,}profile can justly set MAIL and a few others -- this is just letting the user's shell know what it needs to know about the local system. INPUTRC is entirely an individual's decision, and should be left strictly to the individual. >Now here's a candidate for StartupFiles/RedHat/zshrc. Anything badly >wrong? ... ># Set up aliases >alias mv='nocorrect mv' # no spelling correction on mv >alias cp='nocorrect cp' # no spelling correction on cp >alias mkdir='nocorrect mkdir' # no spelling correction on mkdir Evil. mv, cp and mkdir should not be aliases by default; zsh is well established in starting up without any aliases by default. As before, don't change zsh's default; a user that wants to achieve a particular effect with zsh is forced to check this sort of startup file to see which desired zsh defaults get broken and need to be restated explicitly in the personal startup file. ># Where to look for autoloaded function definitions >fpath=( > ~/{lib/zsh,.zsh}/{functions,scripts}(N) > ~/.z{sh,}func*(N) > $fpath > /usr/doc/zsh*/Functions(N) > ) > >typeset -U fpath zsh has a perfectly sensible default. You're adding to the fpath a bunch of directories that the user may or may not want in their fpath, making an assumption that is not always correct, to achieve a convenience that the user can't rely on. ># Autoload all shell functions from all directories ># in $fpath that have the executable bit on ># (the executable bit is not necessary, but gives ># you an easy way to stop the autoloading of a ># particular shell function). >for dirname in $fpath >do > fns=( $dirname/*(N.x:t) ) > (( $#fns )) && autoload $fns >done It's a neat trick, if someone wants to do that. Personally I don't like to handle my fpath that way, and I suspect that most people don't really want those execute bit semantics. Don't stuff it down people's throats. >PS1='%n@%m %B%3~%b %# ' # default prompt Just don't. As before, you're overriding a perfectly reasonable default and imposing your arbitrary tastes on people. In addition, there's a particular problem with PS1, when it gets exported, that it affects other shells that get called that have a different PS1 syntax. (This is particularly visible, for example, when execing zsh from /bin/sh on a stock Red Hat.) Hmm, that doesn't leave anything for /etc/zshrc or /etc/zshenv, and I can't see any valid reason for either of those files to be non-empty. Similarly /etc/zlogin, for that matter, and I think that /etc/zprofile should only mirror the contents of /etc/profile. So here's my recomendation for zsh RPM builders: ship no /etc/zshrc, /etc/zshenv, /etc/zlogin or /etc/zlogout, and have /etc/zprofile be a symbolic link -> profile. (This still leaves a broken Red Hat /etc/profile, but that's outside the scope of a zsh package.) If you want to have fancy example startup files, go ahead and put them in /etc/skel -- that's what it's there for. And my suggestion for zsh-workers: let's get rid of /etc/z*. They're just confusing things. /etc/profile is useful, the rest are just invitations to tread on users' toes. So let's have zsh process /etc/profile first thing (but only in a login shell), and not look at anything else in /etc. I suggest a configure option to support the current set of files, for those few people that really do need them. In fact, configure already has the right options, we just need to change their behaviour a bit. The only annoying thing left is that the global zprofile is run *after* the user's .zshenv. This really ought to be the other way round, to match the usage of /etc/profile. It seems that a distinction must be made between profile and zprofile. The patch below is NOT committed due to anticipated controversy -- I'd like to see a consensus on this before implementing such a significant change in default behaviour. It would implement what I suggest above: all global rc files are disabled by default (enableable with --enable-z{profile,sh{env,rc},log{in,out}}=PATH), and /etc/profile used by default instead (disableable with --disable-profile). There are consequent documentation changes. -zefram Index: configure.in =================================================================== RCS file: /cvsroot/zsh/zsh/configure.in,v retrieving revision 1.12 diff -c -r1.12 configure.in *** configure.in 2000/07/07 17:12:17 1.12 --- configure.in 2000/07/18 01:50:18 *************** *** 113,123 **** AC_ARG_ENABLE(zshenv, [ --enable-zshenv=pathname the full pathname of the global zshenv script], [zshenv="$enableval"], ! [if test "x$etcdir" = xno; then ! zshenv=no ! else ! zshenv="$etcdir/zshenv" ! fi]) if test "x$zshenv" != xno; then AC_DEFINE_UNQUOTED(GLOBAL_ZSHENV, "$zshenv") fi --- 113,119 ---- AC_ARG_ENABLE(zshenv, [ --enable-zshenv=pathname the full pathname of the global zshenv script], [zshenv="$enableval"], ! [zshenv=no]) if test "x$zshenv" != xno; then AC_DEFINE_UNQUOTED(GLOBAL_ZSHENV, "$zshenv") fi *************** *** 126,136 **** AC_ARG_ENABLE(zshrc, [ --enable-zshrc=pathname the full pathname of the global zshrc script], [zshrc="$enableval"], ! [if test "x$etcdir" = xno; then ! zshrc=no ! else ! zshrc="$etcdir/zshrc" ! fi]) if test "x$zshrc" != xno; then AC_DEFINE_UNQUOTED(GLOBAL_ZSHRC, "$zshrc") fi --- 122,128 ---- AC_ARG_ENABLE(zshrc, [ --enable-zshrc=pathname the full pathname of the global zshrc script], [zshrc="$enableval"], ! [zshrc=no]) if test "x$zshrc" != xno; then AC_DEFINE_UNQUOTED(GLOBAL_ZSHRC, "$zshrc") fi *************** *** 139,149 **** AC_ARG_ENABLE(zprofile, [ --enable-zprofile=pathname the full pathname of the global zprofile script], [zprofile="$enableval"], ! [if test "x$etcdir" = xno; then ! zprofile=no ! else ! zprofile="$etcdir/zprofile" ! fi]) if test "x$zprofile" != xno; then AC_DEFINE_UNQUOTED(GLOBAL_ZPROFILE, "$zprofile") fi --- 131,137 ---- AC_ARG_ENABLE(zprofile, [ --enable-zprofile=pathname the full pathname of the global zprofile script], [zprofile="$enableval"], ! [zprofile=no]) if test "x$zprofile" != xno; then AC_DEFINE_UNQUOTED(GLOBAL_ZPROFILE, "$zprofile") fi *************** *** 152,162 **** AC_ARG_ENABLE(zlogin, [ --enable-zlogin=pathname the full pathname of the global zlogin script], [zlogin="$enableval"], ! [if test "x$etcdir" = xno; then ! zlogin=no ! else ! zlogin="$etcdir/zlogin" ! fi]) if test "x$zlogin" != xno; then AC_DEFINE_UNQUOTED(GLOBAL_ZLOGIN, "$zlogin") fi --- 140,146 ---- AC_ARG_ENABLE(zlogin, [ --enable-zlogin=pathname the full pathname of the global zlogin script], [zlogin="$enableval"], ! [zlogin=no]) if test "x$zlogin" != xno; then AC_DEFINE_UNQUOTED(GLOBAL_ZLOGIN, "$zlogin") fi *************** *** 165,184 **** AC_ARG_ENABLE(zlogout, [ --enable-zlogout=pathname the full pathname of the global zlogout script], [zlogout="$enableval"], ! [if test "x$etcdir" = xno; then ! zlogout=no ! else ! zlogout="$etcdir/zlogout" ! fi]) if test "x$zlogout" != xno; then AC_DEFINE_UNQUOTED(GLOBAL_ZLOGOUT, "$zlogout") fi AC_SUBST(zshenv)dnl AC_SUBST(zshrc)dnl AC_SUBST(zprofile)dnl AC_SUBST(zlogin)dnl AC_SUBST(zlogout)dnl dnl Do you want dynamically loaded binary modules. undefine([dynamic])dnl --- 149,174 ---- AC_ARG_ENABLE(zlogout, [ --enable-zlogout=pathname the full pathname of the global zlogout script], [zlogout="$enableval"], ! [zlogout=no]) if test "x$zlogout" != xno; then AC_DEFINE_UNQUOTED(GLOBAL_ZLOGOUT, "$zlogout") fi + undefine([profile])dnl + AC_ARG_ENABLE(profile, + [ --enable-profile=pathname the full pathname of the global profile script], + [profile="$enableval"], + [profile=/etc/profile]) + if test "x$profile" != xno; then + AC_DEFINE_UNQUOTED(GLOBAL_PROFILE, "$profile") + fi + AC_SUBST(zshenv)dnl AC_SUBST(zshrc)dnl AC_SUBST(zprofile)dnl AC_SUBST(zlogin)dnl AC_SUBST(zlogout)dnl + AC_SUBST(profile)dnl dnl Do you want dynamically loaded binary modules. undefine([dynamic])dnl Index: Src/init.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/init.c,v retrieving revision 1.6 diff -c -r1.6 init.c *** Src/init.c 2000/07/13 17:06:19 1.6 --- Src/init.c 2000/07/18 01:50:25 *************** *** 831,836 **** --- 831,840 ---- } else source("/etc/suid_profile"); } else { + #ifdef GLOBAL_PROFILE + if (islogin) + source(GLOBAL_PROFILE); + #endif #ifdef GLOBAL_ZSHENV source(GLOBAL_ZSHENV); #endif Index: acconfig.h =================================================================== RCS file: /cvsroot/zsh/zsh/acconfig.h,v retrieving revision 1.4 diff -c -r1.4 acconfig.h *** acconfig.h 2000/07/04 08:44:03 1.4 --- acconfig.h 2000/07/18 01:50:00 *************** *** 31,51 **** /***** shouldn't have to change anything below here *****/ @TOP@ ! /* The global file to source absolutely first whenever zsh is run; * ! * if undefined, don't source anything */ ! #undef GLOBAL_ZSHENV /* The global file to source whenever zsh is run; * * if undefined, don't source anything */ ! #undef GLOBAL_ZSHRC ! ! /* The global file to source whenever zsh is run as a login shell; * ! * if undefined, don't source anything */ ! #undef GLOBAL_ZLOGIN /* The global file to source whenever zsh is run as a login shell, * * before zshrc is read; if undefined, don't source anything */ #undef GLOBAL_ZPROFILE /* The global file to source whenever zsh was run as a login shell. * * This is sourced right before exiting. If undefined, don't source * --- 31,55 ---- /***** shouldn't have to change anything below here *****/ @TOP@ ! /* The global file to source first whenever zsh is run as a login shell, * ! * before anything else is read; if undefined, don't source anything */ ! #undef GLOBAL_PROFILE /* The global file to source whenever zsh is run; * * if undefined, don't source anything */ ! #undef GLOBAL_ZSHENV /* The global file to source whenever zsh is run as a login shell, * * before zshrc is read; if undefined, don't source anything */ #undef GLOBAL_ZPROFILE + + /* The global file to source whenever zsh is run interactively; * + * if undefined, don't source anything */ + #undef GLOBAL_ZSHRC + + /* The global file to source whenever zsh is run as a login shell, * + * after zshrc is read; if undefined, don't source anything */ + #undef GLOBAL_ZLOGIN /* The global file to source whenever zsh was run as a login shell. * * This is sourced right before exiting. If undefined, don't source * Index: INSTALL =================================================================== RCS file: /cvsroot/zsh/zsh/INSTALL,v retrieving revision 1.1.1.21 diff -c -r1.1.1.21 INSTALL *** INSTALL 2000/03/01 18:31:21 1.1.1.21 --- INSTALL 2000/07/18 01:49:59 *************** *** 246,264 **** Startup/shutdown files ---------------------- ! Zsh has several startup/shutdown files which are in /etc by default. This ! can be overriden using one of the options below when invoking "configure". - --enable-etcdir=directory # default directory for global zsh scripts --enable-zshenv=pathname # the full pathname of the global zshenv script --enable-zshrc=pathname # the full pathname of the global zshrc script --enable-zlogin=pathname # the full pathname of the global zlogin script --enable-zprofile=pathname # the full pathname of the global zprofile script --enable-zlogout=pathname # the full pathname of the global zlogout script ! Any startup/shutdown script can be disabled by giving the ! --disable-scriptname option to "configure". The --disable-etcdir option ! disables all startup/shutdown files which are not explicitely enabled. Shell functions --------------- --- 246,268 ---- Startup/shutdown files ---------------------- ! Global versions of zsh's startup/shutdown files can be configured. These ! are each run just before the corresponding personal startup file (just ! after in the case of zlogout). By default, none of these is enabled. ! This can be overriden using the options below when invoking "configure". --enable-zshenv=pathname # the full pathname of the global zshenv script --enable-zshrc=pathname # the full pathname of the global zshrc script --enable-zlogin=pathname # the full pathname of the global zlogin script --enable-zprofile=pathname # the full pathname of the global zprofile script --enable-zlogout=pathname # the full pathname of the global zlogout script ! Additionally, the pathname of the global profile file can be configured: ! ! --enable-profile=pathname # the full pathname of the global profile script ! ! This defaults to /etc/profile. The profile script can be disabled by ! giving the --disable-profile option to "configure". Shell functions --------------- Index: Doc/Zsh/filelist.yo =================================================================== RCS file: /cvsroot/zsh/zsh/Doc/Zsh/filelist.yo,v retrieving revision 1.2 diff -c -r1.2 filelist.yo *** Doc/Zsh/filelist.yo 2000/04/01 20:43:44 1.2 --- Doc/Zsh/filelist.yo 2000/07/18 01:50:19 *************** *** 7,15 **** list(tt($ZDOTDIR/.zlogin)) list(tt($ZDOTDIR/.zlogout)) list(tt(${TMPPREFIX}*) (default is /tmp/zsh*)) ! list(tt(/etc/zshenv)) ! list(tt(/etc/zprofile)) ! list(tt(/etc/zshrc)) ! list(tt(/etc/zlogin)) ! list(tt(/etc/zlogout) (installation-specific - tt(/etc) is the default)) endlist() --- 7,11 ---- list(tt($ZDOTDIR/.zlogin)) list(tt($ZDOTDIR/.zlogout)) list(tt(${TMPPREFIX}*) (default is /tmp/zsh*)) ! list(tt(/etc/profile)) endlist() Index: Doc/Zsh/files.yo =================================================================== RCS file: /cvsroot/zsh/zsh/Doc/Zsh/files.yo,v retrieving revision 1.2 diff -c -r1.2 files.yo *** Doc/Zsh/files.yo 2000/04/01 20:43:44 1.2 --- Doc/Zsh/files.yo 2000/07/18 01:50:19 *************** *** 7,13 **** cindex(shutdown files) pindex(NO_RCS, use of) pindex(NO_GLOBAL_RCS, use of) ! Commands are first read from tt(/etc/zshenv); this cannot be overridden. Subsequent behaviour is modified by the tt(RCS) and tt(GLOBAL_RCS) options; the former affects all startup files, while the second only affects those in the tt(/etc) directory. If one of the options --- 7,17 ---- cindex(shutdown files) pindex(NO_RCS, use of) pindex(NO_GLOBAL_RCS, use of) ! First, if the shell is a login shell, ! commands are read from the global profile file (by default tt(/etc/profile)). ! Commands are then read from the global zshenv file ! (if one is configured, which it is not by default); ! this cannot be overridden. Subsequent behaviour is modified by the tt(RCS) and tt(GLOBAL_RCS) options; the former affects all startup files, while the second only affects those in the tt(/etc) directory. If one of the options *************** *** 19,32 **** Commands are then read from tt($ZDOTDIR/.zshenv). pindex(LOGIN, use of) If the shell is a login shell, commands ! are read from tt(/etc/zprofile) and then tt($ZDOTDIR/.zprofile). Then, if the shell is interactive, ! commands are read from tt(/etc/zshrc) and then tt($ZDOTDIR/.zshrc). ! Finally, if the shell is a login shell, tt(/etc/zlogin) and ! tt($ZDOTDIR/.zlogin) are read. When a login shell exits, the files tt($ZDOTDIR/.zlogout) and then ! tt(/etc/zlogout) are read. This happens with either an explicit exit via the tt(exit) or tt(logout) commands, or an implicit exit by reading end-of-file from the terminal. However, if the shell terminates due to tt(exec)'ing another process, the logout files are not read. --- 23,43 ---- Commands are then read from tt($ZDOTDIR/.zshenv). pindex(LOGIN, use of) If the shell is a login shell, commands ! are read from the global zprofile file ! (if one is configured, which it is not by default), ! and then tt($ZDOTDIR/.zprofile). Then, if the shell is interactive, ! commands are read from the global zshrc file ! (if one is configured, which it is not by default), ! and then tt($ZDOTDIR/.zshrc). ! Finally, if the shell is a login shell, ! commands are read from the global zlogin file ! (if one is configured, which it is not by default), ! and then tt($ZDOTDIR/.zlogin). When a login shell exits, the files tt($ZDOTDIR/.zlogout) and then ! the global zlogout file (if one is configured, which it is not by default) ! are read. This happens with either an explicit exit via the tt(exit) or tt(logout) commands, or an implicit exit by reading end-of-file from the terminal. However, if the shell terminates due to tt(exec)'ing another process, the logout files are not read. *************** *** 36,45 **** saved. If tt(ZDOTDIR) is unset, tt(HOME) is used instead. - Those files listed above as being in tt(/etc) may be in another - directory, depending on the installation. ! As tt(/etc/zshenv) is run for all instances of zsh, it is important that it be kept as small as possible. In particular, it is a good idea to put code that does not need to be run for every single shell behind a test of the form `tt(if [[ -o rcs ]]; then ...)' so that it will not --- 47,54 ---- saved. If tt(ZDOTDIR) is unset, tt(HOME) is used instead. ! As the global zshenv file is run for all instances of zsh, it is important that it be kept as small as possible. In particular, it is a good idea to put code that does not need to be run for every single shell behind a test of the form `tt(if [[ -o rcs ]]; then ...)' so that it will not Index: Doc/Zsh/options.yo =================================================================== RCS file: /cvsroot/zsh/zsh/Doc/Zsh/options.yo,v retrieving revision 1.9 diff -c -r1.9 options.yo *** Doc/Zsh/options.yo 2000/07/03 08:48:23 1.9 --- Doc/Zsh/options.yo 2000/07/18 01:50:25 *************** *** 415,424 **** cindex(startup files, global, inhibiting) cindex(files, global startup, inhibiting) item(tt(GLOBAL_RCS) (tt(-d)) <D>)( ! If this option is unset, the startup files tt(/etc/zprofile), ! tt(/etc/zshrc), tt(/etc/zlogin) and tt(/etc/zlogout) will not be run. It can be disabled and re-enabled at any time, including inside local startup files (tt(.zshrc), etc.). ) pindex(GLOB_ASSIGN) item(tt(GLOB_ASSIGN) <C>)( --- 415,424 ---- cindex(startup files, global, inhibiting) cindex(files, global startup, inhibiting) item(tt(GLOBAL_RCS) (tt(-d)) <D>)( ! If this option is unset, the global startup files will not be run. It can be disabled and re-enabled at any time, including inside local startup files (tt(.zshrc), etc.). + It does not affect use of the global profile and zshenv. ) pindex(GLOB_ASSIGN) item(tt(GLOB_ASSIGN) <C>)( *************** *** 930,940 **** pindex(RCS) cindex(startup files, sourcing) item(tt(RCS) (tt(PLUS()f)) <D>)( ! After tt(/etc/zshenv) is sourced on startup, source the ! tt(.zshenv), tt(/etc/zprofile), tt(.zprofile), ! tt(/etc/zshrc), tt(.zshrc), tt(/etc/zlogin), tt(.zlogin), and tt(.zlogout) ! files, as described in noderef(Files). ! If this option is unset, the tt(/etc/zshenv) file is still sourced, but any of the others will not be; it can be set at any time to prevent the remaining startup files after the currently executing one from being sourced. --- 930,942 ---- pindex(RCS) cindex(startup files, sourcing) item(tt(RCS) (tt(PLUS()f)) <D>)( ! After the global zshenv is sourced on startup, source the ! tt(.zshenv), the global zprofile, tt(.zprofile), ! the global zshrc, tt(.zshrc), the global zlogin, tt(.zlogin), ! tt(.zlogout) and the global zlogout, ! as described in noderef(Files). ! If this option is unset, ! the global profile and zshenv are still sourced, but any of the others will not be; it can be set at any time to prevent the remaining startup files after the currently executing one from being sourced. END ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PATCH: Re: adding a toplevel zsh.spec.in file 2000-07-18 1:56 ` PATCH: " Zefram @ 2000-07-18 5:22 ` Bart Schaefer 2000-07-18 6:15 ` Wayne Davison 2000-07-18 16:54 ` Trond Eivind Glomsrød 2000-07-18 6:25 ` Andrej Borsenkow ` (2 subsequent siblings) 3 siblings, 2 replies; 12+ messages in thread From: Bart Schaefer @ 2000-07-18 5:22 UTC (permalink / raw) To: Zefram; +Cc: zsh workers mailing list On Jul 18, 2:56am, Zefram wrote: } Subject: PATCH: Re: adding a toplevel zsh.spec.in file } } And my suggestion for zsh-workers: let's get rid of /etc/z*. They're just } confusing things. /etc/profile is useful, the rest are just invitations } to tread on users' toes. So let's have zsh process /etc/profile first } thing (but only in a login shell), and not look at anything else in /etc. I'm fine with most things about this *except* the part about sourcing /etc/profile. I think it's quite sufficient that /etc/profile is read when zsh is emulating sh or ksh. 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. 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? } The only annoying thing left is that the global zprofile is run *after* } the user's .zshenv. Why is that annoying? The .zshenv is run on every shell, but the global zprofile is read only for login shells, and there's always the .zprofile and .zshrc files that are run after the global one. And then there's the recently-added NO_GLOBAL_RCS option, which can be set in .zshenv if the user is really picky. Which I suppose I could set to prevent /etc/profile from being read if it comes to that. Oh, no, it looks like you changed that, too; I VERY strongly object to that. } I suggest a configure option to support the current set of files, for } those few people that really do need them. In fact, configure already } has the right options, we just need to change their behaviour a bit. 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. A good example of this is the RedHat umask setting that Adam and I were just discussing. Since RedHat made the decision to put every user in a separate group -- something that baffles me to this day; maybe Trond is reading this and knows the reasoning -- it follows that they should set an appropriate umask, and that they'd prefer that umask to be set in as many shells as possible -- not just login shells, since may shells started e.g. in xterms are not login shells and may not even be started from within a login shell (consider xrsh or xon). } This really ought to be the other way round, to } match the usage of /etc/profile. It seems that a distinction must be } made between profile and zprofile. To match the usage of ... huh? To match WHAT usage of /etc/profile? The one when emulating ksh? That makes no sense, as the rest of the zsh startup series is not done when emulating ksh; you're comparing totally unrelated cases. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PATCH: Re: adding a toplevel zsh.spec.in file 2000-07-18 5:22 ` Bart Schaefer @ 2000-07-18 6:15 ` Wayne Davison 2000-07-18 16:54 ` Trond Eivind Glomsrød 1 sibling, 0 replies; 12+ messages in thread From: Wayne Davison @ 2000-07-18 6:15 UTC (permalink / raw) To: zsh workers mailing list On Tue, 18 Jul 2000, Bart Schaefer wrote: > Since RedHat made the decision to put every user in a separate > group -- something that baffles me to this day I read the reason for this, and I kind of like this strategy. Here's the gist of it: We want the default to be for (normal) newly-created files to be only writable by the owner that created them PLUS we want to make it easy for new, group-shared files to be writable by a particular group. In a more "normal" setup, the umask is 022, which requires you to manually "chmod g+w" files that need to be group writable. The RedHat solution is to set a umask of 002 (for non-super users) and to have the default group for each user be one that only the user is a member of. That way, most new files are still only writable by the owner (even with a group-writable permission) PLUS a directory with a sticky-group flag set gets files created in it that are group-writable without having to twiddle any file permissions. Kinda neat. > Obviously the maintainers of those environments believe that there's > value in the settings they place in those files. I think that RedHat/Mandrake would do well to remove all the alias, setopt, and similar setup that is going on in these /etc files and move it into the skel files that get installed for new users. This way a new user gets whatever extra setup the packager thought was desirable AND they can see the options and aliases to be able to tweak them AND an advanced user can just overwrite these files without having to add "unalias" commands and turn off non-default options in otherwise portable rc files. ..wayne.. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PATCH: Re: adding a toplevel zsh.spec.in file 2000-07-18 5:22 ` Bart Schaefer 2000-07-18 6:15 ` Wayne Davison @ 2000-07-18 16:54 ` Trond Eivind Glomsrød 1 sibling, 0 replies; 12+ messages in thread From: Trond Eivind Glomsrød @ 2000-07-18 16:54 UTC (permalink / raw) To: Bart Schaefer; +Cc: Zefram, zsh workers mailing list "Bart Schaefer" <schaefer@candle.brasslantern.com> writes: > A good example of this is the RedHat umask setting that Adam and I were > just discussing. Since RedHat made the decision to put every user in > a separate group -- something that baffles me to this day; maybe Trond > is reading this and knows the reasoning http://www.redhat.com/support/manuals/RHL-6.2-Manual/ref-guide/s1-sysadmin-usr-grps.html#S2-SYSADMIN-PRIV-GROUPS -- Trond Eivind Glomsrød Red Hat, Inc. ^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: PATCH: Re: adding a toplevel zsh.spec.in file 2000-07-18 1:56 ` PATCH: " Zefram 2000-07-18 5:22 ` Bart Schaefer @ 2000-07-18 6:25 ` Andrej Borsenkow 2000-07-18 9:42 ` Peter Stephenson 2000-07-18 18:22 ` Trond Eivind Glomsrød 3 siblings, 0 replies; 12+ messages in thread From: Andrej Borsenkow @ 2000-07-18 6:25 UTC (permalink / raw) To: Zefram, Adam Spiers; +Cc: zsh workers mailing list > > So here's my recomendation for zsh RPM builders: ship no /etc/zshrc, > /etc/zshenv, /etc/zlogin or /etc/zlogout, and have /etc/zprofile > be a symbolic link -> profile. (This still leaves a broken Red Hat > /etc/profile, but that's outside the scope of a zsh package.) Slightly off-topic. It is not generally possible to link zprofile to profile because - 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. 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. May be, it is an overkill. And, may be on Linux everything is different :-) (I was speaking about my system) -andrej ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PATCH: Re: adding a toplevel zsh.spec.in file 2000-07-18 1:56 ` PATCH: " Zefram 2000-07-18 5:22 ` Bart Schaefer 2000-07-18 6:25 ` Andrej Borsenkow @ 2000-07-18 9:42 ` Peter Stephenson 2000-07-18 18:22 ` Trond Eivind Glomsrød 3 siblings, 0 replies; 12+ messages in thread From: Peter Stephenson @ 2000-07-18 9:42 UTC (permalink / raw) To: Zsh hackers list Zefram wrote: > And my suggestion for zsh-workers: let's get rid of /etc/z*. They're just > confusing things. They can be, but I don't think completely altering the interface is the right way to deal with people misusing it. There are perfectly good, if specialised, reasons for adding stuff. I'm exactly at this moment in the middle of installing a version of cygwin with a version of zsh that connects to our Bluetooth chip via the serial port. Using the /etc files is the only easy way of setting this up. This is not supposed to be a sufficient argument on its own --- but if I've got a reason for doing this, so have a lot of other people. Removing this is just cutting off your nose to spite your face. The way forward is to educate people over the use of startup script. They're willing to learn if you explain things to them. -- Peter Stephenson <pws@cambridgesiliconradio.com> Cambridge Silicon Radio, Unit 300, Science Park, Milton Road, Cambridge, CB4 0XL, UK Tel: +44 (0)1223 392070 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PATCH: Re: adding a toplevel zsh.spec.in file 2000-07-18 1:56 ` PATCH: " Zefram ` (2 preceding siblings ...) 2000-07-18 9:42 ` Peter Stephenson @ 2000-07-18 18:22 ` Trond Eivind Glomsrød 2000-07-18 19:57 ` Zefram 3 siblings, 1 reply; 12+ messages in thread From: Trond Eivind Glomsrød @ 2000-07-18 18:22 UTC (permalink / raw) To: Zefram; +Cc: Adam Spiers, zsh workers mailing list Zefram <zefram@fysh.org> writes: > Adam Spiers wrote: > >In /etc/zshenv: > > > > export USER=`id -un` > > export LOGNAME=$USER > > export HOSTNAME=$HOST > > > > # this only on appropriate boxes of course > > export MAIL=/var/spool/mail/$USER > > These, if they exist at all (which is OK if done right), should be in > /etc/zprofile, and duplicated in /etc/profile. They should be set > on *login*, not for every shell I start -- if I want to set MAIL to > somewhere different, that setting should propagate to any subshells I run. > > > HISTSIZE=1000 > > HISTFILE=~/.zshhistory > > SAVEHIST=1000 > > No way. zsh has a perfectly well-established default behaviour > w.r.t. history saving, and if I don't override it I should get zsh's > default, not whatever some RPM builder thought might be nice. > > > export INPUTRC=/etc/inputrc In Red Hat Linux, we do this: if [ -z "$INPUTRC" -a ! -f "$HOME/.inputrc" ]; then INPUTRC=/etc/inputrc fi The reason for this is to make bash 1.x handle 8 bit input - we don't set anything else. > My environment is my own. Of course, and you're free to change it in your own files - but that doesn't mean systems should be set up with sensible values (like specifying NNTPSERVER, MAIL, QTDIR etc. etc). > >Now here's a candidate for StartupFiles/RedHat/zshrc. Anything badly > >wrong? > ... > ># Set up aliases > >alias mv='nocorrect mv' # no spelling correction on mv > >alias cp='nocorrect cp' # no spelling correction on cp > >alias mkdir='nocorrect mkdir' # no spelling correction on mkdir > > Evil. Agreed. Such changes should be in a user's own configuration files. > >PS1='%n@%m %B%3~%b %# ' # default prompt > > Just don't. As before, you're overriding a perfectly reasonable > default and imposing your arbitrary tastes on people. If it makes sense, do it - it's just another default, a user can override it. The default BASH prompt is "bash-2.04#", and changing this to something more sensible is good (IMHO, of course - and if you don't like it, pick your own). > So here's my recomendation for zsh RPM builders: ship no /etc/zshrc, > /etc/zshenv, /etc/zlogin or /etc/zlogout, and have /etc/zprofile > be a symbolic link -> profile. (This still leaves a broken Red Hat > /etc/profile, but that's outside the scope of a zsh package.) It's not broken, it's just not designed to handle zsh - it's designed to handle bash only. Fixing this (setting another default prompt for zsh) should be simple if required. -- Trond Eivind Glomsrød Red Hat, Inc. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PATCH: Re: adding a toplevel zsh.spec.in file 2000-07-18 18:22 ` Trond Eivind Glomsrød @ 2000-07-18 19:57 ` Zefram 2000-07-18 20:07 ` Trond Eivind Glomsrød 0 siblings, 1 reply; 12+ messages in thread From: Zefram @ 2000-07-18 19:57 UTC (permalink / raw) To: Trond Eivind=?iso-8859-1?q?_Glomsr=F8d?= Cc: Zefram, Adam Spiers, zsh workers mailing list Trond Eivind=?iso-8859-1?q?_Glomsr=F8d?= wrote: >Of course, and you're free to change it in your own files - but that >doesn't mean systems should be set up with sensible values (like >specifying NNTPSERVER, MAIL, QTDIR etc. etc). Setting those by default when the user logs in is fine. These do belong in /etc/profile. It's unfortunate that zsh processes .zshenv before /etc/zprofile, as it would be nice to be able to set those things similarly for zsh while allowing the user to override them in .zshenv. >If it makes sense, do it - it's just another default, a user can >override it. The default BASH prompt is "bash-2.04#", and changing >this to something more sensible is good (IMHO, of course - and if you >don't like it, pick your own). I've already described the problem with setting PS1 by default -- PS1 gets inherited by other shells. >It's not broken, it's just not designed to handle zsh - it's designed >to handle bash only. Fixing this (setting another default prompt for >zsh) should be simple if required. Ah, I actually can't find the really nasty bits of default setup (such as enabling colour output from ls) in the recent versions, so this seems to have been fixed (assuming that I'm remembering correctly in that being Red Hat). There are a couple of things where I think it's still overstepping its territory, particularly setting HISTSIZE and INPUTRC, which are matters of interactive shell configuration and so should be left firmly up to the user. (The prompt setting seems to be in /etc/bashrc now, but I don't see when bash executes that.) -zefram ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PATCH: Re: adding a toplevel zsh.spec.in file 2000-07-18 19:57 ` Zefram @ 2000-07-18 20:07 ` Trond Eivind Glomsrød 2000-07-18 20:37 ` Zefram 0 siblings, 1 reply; 12+ messages in thread From: Trond Eivind Glomsrød @ 2000-07-18 20:07 UTC (permalink / raw) To: Zefram, zsh workers mailing list Zefram <zefram@fysh.org> writes: > Trond Eivind Glomsrød wrote: > >Of course, and you're free to change it in your own files - but that > >doesn't mean systems should be set up with sensible values (like > >specifying NNTPSERVER, MAIL, QTDIR etc. etc). > > Setting those by default when the user logs in is fine. These do > belong in /etc/profile. It's unfortunate that zsh processes .zshenv > before /etc/zprofile, as it would be nice to be able to set those things > similarly for zsh while allowing the user to override them in > .zshenv. Agreed - all default system values should be first, then personal. > >If it makes sense, do it - it's just another default, a user can > >override it. The default BASH prompt is "bash-2.04#", and changing > >this to something more sensible is good (IMHO, of course - and if you > >don't like it, pick your own). > > I've already described the problem with setting PS1 by default -- PS1 > gets inherited by other shells. The default value sucks (IMHO) - the alternative is patching the source, which would be much more confusing. The solution for zsh is simple - just set something in your .zshrc. > > >It's not broken, it's just not designed to handle zsh - it's designed > >to handle bash only. Fixing this (setting another default prompt for > >zsh) should be simple if required. > > Ah, I actually can't find the really nasty bits of default setup (such > as enabling colour output from ls) in the recent versions, so this > seems to have been fixed (assuming that I'm remembering correctly in > that being Red Hat). This is now being done by ls itself in a file sourced from /etc/profile.d/ - if you don't like it, convince bero@redhat.com : You'll have a hard time. > There are a couple of things where I think it's > still overstepping its territory, particularly setting HISTSIZE and > INPUTRC, HISTSIZE isn't too bad (you can override it) and /etc/inputrc is necesarry to make bash 1.4x work with non-ASCII characters. When creating a distribution, you have to walk a thin line between those who want the most functionality out of the box and those who don't. We are restrictive in what the default setup does, but some things are necesarry: Like changing the default prompt in bash and enabling 8 bit support. And of course, system configuration: The latter is handled individually by each package from /etc/profile.d -- Trond Eivind Glomsrød Red Hat, Inc. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PATCH: Re: adding a toplevel zsh.spec.in file 2000-07-18 20:07 ` Trond Eivind Glomsrød @ 2000-07-18 20:37 ` Zefram 0 siblings, 0 replies; 12+ messages in thread From: Zefram @ 2000-07-18 20:37 UTC (permalink / raw) To: Trond Eivind=?iso-8859-1?q?_Glomsr=F8d?=; +Cc: Zefram, zsh workers mailing list Trond Eivind=?iso-8859-1?q?_Glomsr=F8d?= wrote: >The default value sucks (IMHO) - the alternative is patching the >source, which would be much more confusing. The solution for zsh is >simple - just set something in your .zshrc. > >HISTSIZE isn't too bad (you can override it) and /etc/inputrc is >necesarry to make bash 1.4x work with non-ASCII characters. Setting the prompt, INPUTRC and so on by default without stepping on users' toes is easy -- just set them in /etc/skel/.{ba,z}shrc. There's no tradeoff required between default functionality and keeping out of the way, there's no fine line to walk, /etc/skel lets you provide arbitrarily clever functionality to users that don't attempt to configure their shells at all while simultaneously leaving the shells' own standard default settings completely unaffected and available to anyone that wants to write their own dotfiles. Given the availability of such a mechanism, any /etc/profile that fiddles with the configuration of an interactive shell can only be regarded as broken. The argument about providing new functionality to users with old dotfiles just doesn't hold water, especially when one is creating a package to be used when setting up a new system, where there are no existing users to be concerned about. -zefram ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2000-07-18 20:37 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-07-18 15:40 PATCH: Re: adding a toplevel zsh.spec.in file zefram 2000-07-18 16:37 ` Andrej Borsenkow -- strict thread matches above, loose matches on Subject: below -- 2000-07-17 15:09 Adam Spiers 2000-07-18 1:56 ` PATCH: " Zefram 2000-07-18 5:22 ` Bart Schaefer 2000-07-18 6:15 ` Wayne Davison 2000-07-18 16:54 ` Trond Eivind Glomsrød 2000-07-18 6:25 ` Andrej Borsenkow 2000-07-18 9:42 ` Peter Stephenson 2000-07-18 18:22 ` Trond Eivind Glomsrød 2000-07-18 19:57 ` Zefram 2000-07-18 20:07 ` Trond Eivind Glomsrød 2000-07-18 20:37 ` Zefram
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).