Re: Feature discussion - startup files

[Greg Wooledge]

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