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