adding a toplevel zsh.spec.in file

adding a toplevel zsh.spec.in file

[Adam Spiers]

Hi all,

I would like to add a zsh.spec.in file to the toplevel directory so
that any tarball releases or CVS snapshots can immediately be built
into RPMs with

  $ rpm -ta zsh-3.1.x-dev-y.tar.gz

Are there any objections to this?  If not there are a few issues to
clear up:

 - Do we also bundle a zsh.spec in releases?  I vote yes, otherwise
   the whole exercise is a bit pointless.

 - Should zsh.spec be included in the CVS tree?  Yes goes against the
   grain, since all other auto-generated files aren't, but no means
   that CVS snapshots can't be built immediately as above.

 - I would like to include some sample startup files for a typical
   RedHat box.  I already have these - taken from an official RedHat
   zsh rpm, and then much improved (mainly through suggestions from
   Bart).  Would it be OK to add these in a new StartupFiles/RedHat
   directory?  Or is it time that the current StartupFiles files
   (written for 2.7) got a rehaul anyway?

Adam

Re: adding a toplevel zsh.spec.in file

[Peter Stephenson]

> Hi all,
> 
> I would like to add a zsh.spec.in file to the toplevel directory so
> that any tarball releases or CVS snapshots can immediately be built
> into RPMs with
> 
>   $ rpm -ta zsh-3.1.x-dev-y.tar.gz
> 
> Are there any objections to this?  If not there are a few issues to
> clear up:
> 
>  - Do we also bundle a zsh.spec in releases?  I vote yes, otherwise
>    the whole exercise is a bit pointless.

That won't be a problem.  Just add it to .distfiles.

>  - Should zsh.spec be included in the CVS tree?  Yes goes against the
>    grain, since all other auto-generated files aren't, but no means
>    that CVS snapshots can't be built immediately as above.

It's not worth it; you can't bundle a raw CVS tree anyway, you have to run
preconfig.  Get that to do any pre-configuation stuff.

>  - I would like to include some sample startup files for a typical
>    RedHat box.  I already have these - taken from an official RedHat
>    zsh rpm, and then much improved (mainly through suggestions from
>    Bart).  Would it be OK to add these in a new StartupFiles/RedHat
>    directory?  Or is it time that the current StartupFiles files
>    (written for 2.7) got a rehaul anyway?

It's ancient, it really should be completely rewritten and preferably
divided up into indiviual files doing different things, with any compctl
stuff stuck in a subdirectory for legacy code.

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: adding a toplevel zsh.spec.in file

[Chmouel Boudjnah]

Adam Spiers <adam@spiers.net> writes:

> Hi all,
> 
> I would like to add a zsh.spec.in file to the toplevel directory so
> that any tarball releases or CVS snapshots can immediately be built
> into RPMs with
> 
>   $ rpm -ta zsh-3.1.x-dev-y.tar.gz
> 
> Are there any objections to this?  If not there are a few issues to
> clear up:

Be careful you'll have by the way need to fight with the
RPM_BUILD_ROOT in the %install :

--- zsh-3.1.9/Src/zsh.mdd.chmou Tue Jul  4 10:06:32 2000
+++ zsh-3.1.9/Src/zsh.mdd       Tue Jul  4 10:54:11 2000
@@ -53,8 +53,10 @@
            rm -f zshpaths.h.tmp; \
            echo "\`zshpaths.h' is up to date." ; \
        else \
+           if [ ! -f .in_rpm_install ]; then \
            mv -f zshpaths.h.tmp zshpaths.h; \
            echo "Updated \`zshpaths.h'." ; \
+           fi; \
        fi
 
 bltinmods.list: modules.stamp modules-bltin xmods.conf mkbltnmlst.sh

and this in %install :

# Zsh hardcode the prefix in binary even at install.
pushd Src/ && {
    touch .in_rpm_install
    %makeinstall
} && popd

(%makinstall is new macros of rpm-3.0.5 combined with %configure)
-- 
MandrakeSoft Inc                http://www.mandrakesoft.com
San-Francisco, CA USA                             --Chmouel

Re: adding a toplevel zsh.spec.in file

[Adam Spiers]

Chmouel Boudjnah (chmouel@mandrakesoft.com) wrote:
> Be careful you'll have by the way need to fight with the
> RPM_BUILD_ROOT in the %install :
> 
> --- zsh-3.1.9/Src/zsh.mdd.chmou Tue Jul  4 10:06:32 2000
> +++ zsh-3.1.9/Src/zsh.mdd       Tue Jul  4 10:54:11 2000
> @@ -53,8 +53,10 @@
>             rm -f zshpaths.h.tmp; \
>             echo "\`zshpaths.h' is up to date." ; \
>         else \
> +           if [ ! -f .in_rpm_install ]; then \
>             mv -f zshpaths.h.tmp zshpaths.h; \
>             echo "Updated \`zshpaths.h'." ; \
> +           fi; \
>         fi
>  
>  bltinmods.list: modules.stamp modules-bltin xmods.conf mkbltnmlst.sh
> 
> and this in %install :
> 
> # Zsh hardcode the prefix in binary even at install.
> pushd Src/ && {
>     touch .in_rpm_install
>     %makeinstall
> } && popd

Are you sure?  I've built many rpms of zsh in the past, and if you're
talking about the problem I think you are, I got around them by using
DESTDIR:

%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/usr/info $RPM_BUILD_ROOT/bin $RPM_BUILD_ROOT/etc $RPM_B
UILD_ROOT/etc/zprofile.d $RPM_BUILD_ROOT/usr/bin $RPM_BUILD_ROOT/usr/lib $RPM_BU
ILD_ROOT/usr/doc/zsh-%{version}

make DESTDIR=$RPM_BUILD_ROOT install
make DESTDIR=$RPM_BUILD_ROOT install.modules
make DESTDIR=$RPM_BUILD_ROOT install.info

Re: adding a toplevel zsh.spec.in file

[Bart Schaefer]

On Jul 7, 12:53pm, Adam Spiers wrote:
} Subject: adding a toplevel zsh.spec.in file
}
}  - I would like to include some sample startup files for a typical
}    RedHat box.  I already have these - taken from an official RedHat
}    zsh rpm, and then much improved (mainly through suggestions from
}    Bart).  Would it be OK to add these in a new StartupFiles/RedHat
}    directory?  Or is it time that the current StartupFiles files
}    (written for 2.7) got a rehaul anyway?

The stuff in StartupFiles was never intended to be placed in the /etc/z*
files.  It was intended as examples that people might want to selectively
copy (as in, command by command, not whole files) to their own .z* files.

If we're going to add, or replace it with, stuff that IS intended to go
in /etc/z*, there should be some kind of README or other explanatory file
added as well.

-- 
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: adding a toplevel zsh.spec.in file

[Zefram]

Bart Schaefer wrote:
>If we're going to add, or replace it with, stuff that IS intended to go
>in /etc/z*, there should be some kind of README or other explanatory file
>added as well.

Is there anything that ought to go in /etc/z* on more machines than,
say, those in a single company?  It seems to me that Red Hat and
other Linux distributions should be shipping with no (or empty)
/etc/{profile,z{sh{env,rc},profile,login},csh.*} files.  We *should*
add a README explaining how the existing example files are meant to
be used, and explaining why it's usually a bad idea to put anything in
global shell startup files.

-zefram

Re: adding a toplevel zsh.spec.in file

[Bart Schaefer]

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.

As of the zsh-3.0.5-6 RPM, which shipped with RH6, the /etc/zlogin and
/etc/zprofile files contained only comments, /etc/zlogout contained the
"clear" command, and /etc/zshenv set $X11HOME and the path.  This is all
fine.  However, /etc/zshrc contained aliases and bindkeys, which has
always annoyed me.

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

Re: adding a toplevel zsh.spec.in file

[Bart Schaefer]

On Jul 17,  4:09pm, Adam Spiers wrote:
} Subject: Re: adding a toplevel zsh.spec.in file
}
} 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?

I suggested that zshrc was better than zprofile (and that it should
be in only one or the other, and not both as it was).  Neither of those
catches non-interactive processes, so I wasn't addressing that at all.

In the case of RedHat's umask setting, which involves executing $(id -gn)
and several other tests, I'd say that avoiding the startup overhead is
more important for non-interactive shells.  If it's really a problem for
some reason, set umask conservatively in zshenv and then do the tests in
zshrc to relax the umask if appropriate.

} 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

I agree that these don't do much harm, but this is bad:

}   HISTSIZE=1000
}   HISTFILE=~/.zshhistory
}   SAVEHIST=1000

Please don't mess with the shape of my history or the location of any of
my dotfiles.

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

Some system administrators believe in hiding system administration commands
from users who are not system administrators.  I don't care one way or the
other.

} Now here's a candidate for StartupFiles/RedHat/zshrc.  Anything badly
} wrong?

Yes.  Don't screw with my fpath and don't autoload functions for me.  I
very carefully set fpath and autoload functions in stages so that some
functions are available in non-interactive shells, and I don't use the
execute bit to mean anything nor should I be required to do so.  Your
assumptions about where under my home directory there might be functions
are wrong, and if your RPM is built correctly there shouldn't be anything
useful in /usr/doc/zsh*/Functions -- the only things that could be there
are leftovers from some 3.0.x-y RPM, which you don't want to pick up.

I won't call the aliases "badly" wrong, but I object to them anyway, and
I'd just as soon not have all that crap in my prompt, thanks.  Which I
guess means I think /etc/zshrc should be empty (except maybe for umask
as discussed above).

-- 
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: adding a toplevel zsh.spec.in file

[Adam Spiers]

Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
> I agree that these don't do much harm, but this is bad:
> 
> }   HISTSIZE=1000
> }   HISTFILE=~/.zshhistory
> }   SAVEHIST=1000
> 
> Please don't mess with the shape of my history or the location of any of
> my dotfiles.

Why is this messing with your preferences?  It's only setting a
default which each user can override, surely?

> } Now here's a candidate for StartupFiles/RedHat/zshrc.  Anything badly
> } wrong?
> 
> Yes.  Don't screw with my fpath and don't autoload functions for me.

Again, I must be missing something because I don't see why you
describe this as messing with /your/ fpath when at that stage you (the
user) haven't made any changes to it.  You are still free to set it to
whatever you want, aren't you?  The only possible problem I can
envisage is that something gets autoloaded which you didn't want to
be, but if you didn't want it autoloaded, you won't be using it
anyway.  What am I missing?

> Your assumptions about where under my home directory there might be
> functions are wrong,

I wanted to err on the side of convenience.  If those directories
exist, the likelihood is that they contain stuff which the user will
want to use.  If they don't, they don't get included.  What's the
harm?

> and if your RPM is built correctly there shouldn't be anything
> useful in /usr/doc/zsh*/Functions -- the only things that could be there
> are leftovers from some 3.0.x-y RPM, which you don't want to pick up.

Yep, this is a remnant from old code.

> I won't call the aliases "badly" wrong, but I object to them anyway,

I'm curious now.  Why?

> and I'd just as soon not have all that crap in my prompt, thanks.

Just another default, surely?

I have a nasty feeling I've missed a key point here.

Re: adding a toplevel zsh.spec.in file

[Oliver Kiddle]

I very much agree with Bart on these points.

If we are going to have default /etc/z* files in a generated rpm package
they should be as minimal as possible. We should stress the point to
people installing zsh that they should only put things in global setup
files that really should be in them. My definition of that is only
things which are necessary for the specifics of the local setup so only
adding a few things to the PATH and setting any variables necessary for
programs to run.

Adam Spiers wrote:

> > }   HISTSIZE=1000
> > }   HISTFILE=~/.zshhistory

> Why is this messing with your preferences?  It's only setting a
> default which each user can override, surely?

Maybe a user can override it but it isn't necessarily obvious whether
the significant value for these variables is the first or last value
they get. I never trust these things until I've checked them out. I also
sometimes like to know that I have a clean zsh when I run it as a
different user or whatever.

If we want to provide examples of clever zsh startup files which enable
all the bells and whistles, I think it is much better to put them on the
web page where they can clearly be labeled as what they are. Anything in
the distribution is likely to be taken as something which is supposed to
be installed in /etc.

Oliver

Re: adding a toplevel zsh.spec.in file

[Adam Spiers]

Oliver Kiddle (opk@u.genie.co.uk) wrote:
> I very much agree with Bart on these points.
> 
> If we are going to have default /etc/z* files in a generated rpm package
> they should be as minimal as possible. We should stress the point to
> people installing zsh that they should only put things in global setup
> files that really should be in them. My definition of that is only
> things which are necessary for the specifics of the local setup so only
> adding a few things to the PATH and setting any variables necessary for
> programs to run.
> 
> Adam Spiers wrote:
> 
> > > }   HISTSIZE=1000
> > > }   HISTFILE=~/.zshhistory
> 
> > Why is this messing with your preferences?  It's only setting a
> > default which each user can override, surely?
> 
> Maybe a user can override it but it isn't necessarily obvious whether
> the significant value for these variables is the first or last value
> they get. I never trust these things until I've checked them out. I also
> sometimes like to know that I have a clean zsh when I run it as a
> different user or whatever.
> 
> If we want to provide examples of clever zsh startup files which enable
> all the bells and whistles,

The scripts I'm talking about are far far away from enabling bells and
whistles.  They just have a few things to smooth the edges of an
otherwise very raw installation.

[As an aside, I sometimes wonder why we don't make a
bells-and-whistles out of the box install of zsh much more easily
obtainable.  After all, the vast majority of people only use zsh for
its bells and whistles.]

> I think it is much better to put them on the
> web page where they can clearly be labeled as what they are.

Or in the example startups, but commented out.  Remember, if we
provide a decent set of RedHat (say) startup scripts, it's likely that
within two years every recent RedHat box will have them installed, and
most people aren't going to be looking at the zsh web site when
they're editing them.

> Anything in the distribution is likely to be taken as something
> which is supposed to be installed in /etc.

Which is exactly what StartupFiles/RedHat/* would be, no?

Re: adding a toplevel zsh.spec.in file

[Trond Eivind Glomsrød]

Adam Spiers <adam@spiers.net> writes:

> > I think it is much better to put them on the
> > web page where they can clearly be labeled as what they are.
> 
> Or in the example startups, but commented out.  Remember, if we
> provide a decent set of RedHat (say) startup scripts, it's likely that
> within two years every recent RedHat box will have them installed, and
> most people aren't going to be looking at the zsh web site when
> they're editing them.

If you want to coordinate spec files, that's fine with me.

If there are any suggestions on changes to be made on them, feel free
to contact me.
-- 
Trond Eivind Glomsrød
Red Hat, Inc.

Re: adding a toplevel zsh.spec.in file

[Bart Schaefer]

On Jul 17,  7:07pm, Adam Spiers wrote:
} Subject: Re: adding a toplevel zsh.spec.in file
}
} Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
} > I agree that these don't do much harm, but this is bad:
} > 
} > }   HISTSIZE=1000
} > }   HISTFILE=~/.zshhistory
} > }   SAVEHIST=1000
} > 
} > Please don't mess with the shape of my history or the location of any of
} > my dotfiles.
} 
} Why is this messing with your preferences?  It's only setting a
} default which each user can override, surely?

It's setting a default other than the documented one, which I should not
be required to override when the documented behavior is already as I
prefer it.

} > } Now here's a candidate for StartupFiles/RedHat/zshrc.  Anything badly
} > } wrong?
} > 
} > Yes.  Don't screw with my fpath and don't autoload functions for me.
} 
} Again, I must be missing something because I don't see why you
} describe this as messing with /your/ fpath when at that stage you (the
} user) haven't made any changes to it.

What?  You said this was in /etc/zshrc.  At that point I *HAVE* made
changes to it, in ~/.zshenv.  But even if I hadn't made any changes, who
are you to say that I *WANTED* any changes?

} You are still free to set it to whatever you want, aren't you?

Once again, I should be able to rely upon the documented defaults, not
be required to reassert them.

} The only possible problem I can
} envisage is that something gets autoloaded which you didn't want to
} be, but if you didn't want it autoloaded, you won't be using it
} anyway.

How do you know I won't be using it?  Somthing that you autoloaded may
have the same name as an external executable, which is now masked.  To
get the external executable back, I have to know to unfunction things
you autoloaded.  No, thank you.

} > Your assumptions about where under my home directory there might be
} > functions are wrong,
} 
} I wanted to err on the side of convenience.

Please err on the side of my sanity instead.

} > I won't call the aliases "badly" wrong, but I object to them anyway,
} 
} I'm curious now.  Why?

Zefram has explained, if it wasn't already clear from my remarks above.

Further, who are you to decide that I don't want the first N-1 arguments
of cp and mv to be corrected, just because it would be wrong to correct
the Nth one?

} > and I'd just as soon not have all that crap in my prompt, thanks.
} 
} Just another default, surely?

Just another not-the-documented-default.

On Jul 18, 12:35am, Adam Spiers wrote:
} Subject: Re: adding a toplevel zsh.spec.in file
}
} [As an aside, I sometimes wonder why we don't make a
} bells-and-whistles out of the box install of zsh much more easily
} obtainable.  After all, the vast majority of people only use zsh for
} its bells and whistles.]

Sigh.  This is exactly the reason that a whole bunch of default setopts
got turned on in 3.1 that used to be turned off in 3.0.  I still remain
unconvinced that it was a good idea, though I've largely given up on
complaining about it (except for the occasional pot-shot like this).

Bells and whistles are great when one understands what's happening.  One
is more likely to understand what's happening if one has to take some
kind of action to make it so.  Otherwise, the more things that happen,
the more confused one becomes.  For most instances of "one".

} > Anything in the distribution is likely to be taken as something
} > which is supposed to be installed in /etc.
} 
} Which is exactly what StartupFiles/RedHat/* would be, no?

Yes, which is exactly why they ought to have nothing in them that is not
absolutely essential to making every RedHat system work correctly.

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

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

How to distribute skeleton zshrc etc. (Re: PATCH: Re: adding a toplevel zsh.spec.in file)

[Bart Schaefer]

On Jul 17, 11:15pm, Wayne Davison wrote:
} Subject: Re: PATCH: Re: adding a toplevel zsh.spec.in file
}
} 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.

The problem with this approach is that the skel files are installed
only when a new user is created, but the package for zsh is an add-on
that can be installed or deinstalled independently.  How do you update
all the users' copies of the skel files when a new version of the zsh
package is installed?  How do you "distribute" skel files to existing
users when zsh is added for the first time?

You can't simply set ZDOTDIR=/etc/skel in /etc/zshenv, that would mess up
a user who has compiled his own copy of zsh (not to mention effectively
making *all* the RCs read-only).  Perhaps a test in /etc/zshrc (or some
similar place that survives the latest proposed changes) for whether any
of the ~/.z{sh{env,rc},profile,login} files exists, and if none do, then
symlink them all from /etc/skel ...

Perhaps zsh should ignore the value of ZDOTDIR until after ~/.zshenv has
been sourced, but also source $ZDOTDIR/.zshenv if no ~/.zshenv exists ...
I hesitate to suggest this because it might actually break my current
personal zsh configuration, but it ought to be a little harder than it
is for a sysadmin to accidentally bypass all user-writable files.  Hmm,
perhaps do the delayed-ZDOTDIR thing only for un-restricted shells?

I'm obviously thinking "out loud" here.

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

[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

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