[Pkg-zsh-devel] On sourcing /etc/profile
ft at bewatermyfriend.org
Mon Oct 24 14:47:04 UTC 2011
Just had a discussion on IRC about whether or not debian's zsh package
should source `/etc/profile'. We could do that by doing this in
emulate sh -c "source /etc/profile"
That does require a pretty recent zsh, but then again, people get that
with a new package anyway. So that is not a problem.
What it does is: it sources /etc/profile with the sh-compatibility mode
turned on. Which should work with the vast majority of shell code. That
is the best we can do about this. (Side note: There's an OS - I won't
say which - that turns zsh's zprofile file to /etc/profile via a
compile-time option... I don't have words for how wrong that is.)
The question however is this: Should we do that at all? The only thing I
see to do that is to have a common place to configure $PATH across
(bourne-like) shells. But then, that's probably still wrong because if
over time $PATH changes (gets extended or what-not), old /etc/profile
files are not replaced by new ones.
Excursion: There could be a /etc/PATH file, that lists all files that a
a login system uses to set the default $PATH for the system.
Such a login system could be login(1) or a desktop manager.
The second thing we would get is loading files from `/etc/profile.d/'.
I don't see any reason for having to change a shell environment for any
package. None. It doesn't seem to be in wide use either. bash_completion
and netgen are the two packages I see for now. And the bash_completion
use case is even flawed, too. If I understand things correctly.
To cut a long story short, I'd fear for more ill to come of this than
good. But if everyone else thinks, this is a good idea, then the one
line on top of this mail should do the trick (I didn't test).
Opinions welcome; don't be shy.
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
-- RFC 1925
More information about the Pkg-zsh-devel