Re: Feature discussion - startup files

[Fotis Georgatos]

Hi Greg,

The mere existence of -and ability to manage-, say, /etc/zshenv does not enforce any particular policy

on a given system, it simply allows for the possibility to have a single control point for all shell instances.

Unfortunately, a compile time option for bash, is not a feature at the same level like that of zsh,

since that would imply interfering with the upstream providers' support (think of shellshock and such incidents).

Interestingly, I find kinda control-freak the approach of not permitting a *voluntarily* usable feature,

which is a pretty much a standard facility across many other shells. 

I'd believe it's improper to need to patch batch systems (PBS, SGE etc, another source of horrors in its own merit), in the name of a lacking bash feature, while other shells seem to get the job done as expected: 

* a single point of control for introducing env-modules [1].

However, I gladly encourage you to go forward and raise your concerns in the mailing list, as regards

potentially breaking things, because that may allow to improve upon a technical implementation.

F.

[1] http://modules.sourceforge.net/docs/Modules-Paper.pdf

On 23 December 2015 at 13:05, Greg Wooledge <wooledg@eeg.ccf.org> wrote:

On Mon, Dec 21, 2015 at 03:19:46PM -0500, Chet Ramey wrote:
> I've been approached by some HPC system administrators (who have the
> unenviable task of supporting thousands of users) who have requested a
> new feature in bash: a system startup file with a fixed name (e.g.,
> /etc/bashenv) that is sourced by every instance of bash.  The initial
> request was for something sourced by every interactive shell, but the
> presence of batch systems in the HPC environments prompted the request
> for this kind of startup file for non-interactive shells as well.

On Wed, Dec 23, 2015 at 02:49:14AM -0500, Rob Foehl wrote:
> For whatever it's worth, the way I deal with this is to keep a .profile
> full of POSIX shell to handle most of the environment setup -- including
> undoing the obnoxiousness sourced from vendor files in /etc that I can't
> otherwise convince bash to ignore -- which is in turn sourced by this
> preamble in my .bashrc:

I've kept silent on this topic because I couldn't think of a good thing
to say.  But I'd like to point out these two diametrically opposed
goals, and how it makes Chet's job extremely difficult.

On the one hand, we have draconian control-freak admins who want to
impose their policy on every user unconditionally, through things
like /etc/bash.bashrc (or /etc/bashrc or however the vendor chooses
to spell it).  And now apparently even that's not enough for them.
They want to control SCRIPTS too.

On the other hand, we have users like Rob, and like me, who just want
a vanilla environment with no interference and no surprises.

Now, as I said, I'm on the second team, so clearly I am biased, but I
can't think of any good outcomes from a control-freak admin deciding to
inject code into every single script that runs on a system.  That's going
to break things.  A *lot* of things.

Nevertheless, if admins want to break their systems, it's not my place
to stop them.  A compile-time option for /etc/bashenv (just like the
compile-time option for /etc/bash.bashrc et al.) would give them what
they want, and the rest of us can just undo that damage locally, the
same way we undo the damage from /etc/bash.bashrc and /etc/skel/.bashrc
and whatever else they try to inflict on us.  Or we can walk away.

Nothing can stop a vendor from enabling/disabling the features they
want when they compile bash, so any pretense of this filename becoming
universally extant is just fantasy.  Even if Chet were to force it
into bash without a documented option in config-top.h, a vendor could
still patch it away.  It would just take a tiny bit more effort.

(Plus, y'know, there are millions of instances of bash already that
don't have it.  Most of those will not go away any time soon.)

tl;dr: I won't complain if Chet makes this a compile-time option, but
I would prefer that it default to "not enabled".

--

 

echo "sysadmin know better bash than english"|sed s/min/mins/ \
  | sed 's/better bash/bash better/' # signal detected in a CERN forum