Hi, I much align to Piotr's approach to this. And I'd reiterate his important question: "How much harm can it do?" Well, really, if there is a counter argument to inventing such a hook, please put it forward now, because it needs to be considered.
I wish config-top.h or configure would be a solution, yet asking all vendors to tune to it, sounds like an exercise in vain; meanwhile, they would be more willing to receive a new feature from upstream bash, which is optional and does no harm. tia for your time, F. On 21 December 2015 at 21:43, Piotr Grzybowski <narsil...@gmail.com> wrote: > Hey, > > As an administrator, when I faced this issue I usually used some > wicked sourcing in standard bash startup files to get one global file > that gets sourced by default (last time I wanted one per group of > users, etc). > It would be useful; at least for me. How much harm can it do? If the > file is no existent, the behaviour is unchanged. There is no > significant performance impact. If it is plainly mentioned in the man > I have no problem with enabling it by default. > Personally I think that the list should be used to propose the new > features, and ask for them. When the maintainer is being approached > and then he approaches the list it may stop some (not all ;-)) to > shout "what a stupid idea that is". > > sincerely, > pg > > > On Mon, Dec 21, 2015 at 9:19 PM, Chet Ramey <chet.ra...@case.edu> 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. > > > > The current configurable startup file options are insufficient for their > > purposes because they can be enabled or disabled by vendors, and these > > folks would rather not modify the "vendor" parts of the system. In some > > cases, with some Linux distributions, doing so voids their support. > > > > My position is that a feature like this is not popular enough to be made > > the default, and the way to move forward and make something like it > > available is to make it a configurable option. The standard way to do > > that is to make it an option in config-top.h, but it could be settable > > using configure. > > > > I'm interested in hearing what other folks think about the issue, and > > the shell configuration challenges system administrators face in general. > > > > Chet > > -- > > ``The lyf so short, the craft so long to lerne.'' - Chaucer > > ``Ars longa, vita brevis'' - Hippocrates > > Chet Ramey, ITS, CWRU c...@case.edu > http://cnswww.cns.cwru.edu/~chet/ > > > -- echo "sysadmin know better bash than english"|sed s/min/mins/ \ | sed 's/better bash/bash better/' # signal detected in a CERN forum
