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

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

[zefram]

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

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

[Andrej Borsenkow]

>
> /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

Re: adding a toplevel zsh.spec.in file

[Adam Spiers]

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

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

[Zefram]

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

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

[Bart Schaefer]

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   

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

[Wayne Davison]

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

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

[Trond Eivind Glomsrød]

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

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

[Andrej Borsenkow]

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

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

[Peter Stephenson]

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

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

[Trond Eivind Glomsrød]

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.

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

[Zefram]

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

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

[Trond Eivind Glomsrød]

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.

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

[Zefram]

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