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

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

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