(Advance apologies if this has been seen before, this is my third
attempt to send it. -- scs )
A regular problem with most shells is that when logging via the common
X window logins (xdm and its more modern descendants for cde, gnome, kde,
etc) the initial shell started is neither interactive nor a login shell.
Thus logging onto a workstation console gives a considerably different
initialization process than logging in via ssh. Here are some of the
workarounds bash users and system admins are doing to handle this:
1. Put everything in .bashrc
The most common is to simply pack everything into .bashrc and make
sure ENV=~/.bashrc. This works, but reduces the intended functionality
of ENV and winds up doing a lot of redundant processing. By redundant
processing, I mean things that need only be done once - setting paths,
exporting variables and functions, etc, etc. If processing the
.bashrc involves invoking other scripts, files, etc, the amount of
redundant processing can be considerable.
It also means people must attempt to intuit interactive processing
and handle it manually.
2. Manual setups of a file that is executed only once per session,
where 'session' is defined as from login to logout, regardless
of the login method. I do this one myself by putting 'setenv',
path settings, exported functions, etc, into a .bash_once file
and beginning all the other .bash* files with (simplified):
if [ "" = "$SET_ONCE" ] ; then
if [ -f ~/.bash_once ] ; then
. ~/.bash_once
fi
fi
The ~/.bash_once file begins by checking for SET_ONCE and returning
if it's already set. If it isn't already set, it sets SET_ONCE to
the name of the file like a path and goes on to do all inheritable
settings and lot of expensive one-time processing. As an example of
'expensive one-time processing', I weed duplicate entries out of
the PATH, eliminate non-existent directories from it (yeah, you
could argue against that. so don't do it in your own files - this
is an example), use the PATH to build MANPATH by converting 'bin'
to 'man' (again checking for non-existent directories), etc, etc, etc.
It also means people must attempt to intuit interactive processing
and handle it manually.
The end result of all of this is that the .bashrc file is now seven
executable lines after the SET_ONCE check and comments, the
.bash_login is simply
if [ -f ~/.bashrc ] ; then . ~/.bashrc ; fi
and the .bash_once is 360+ lines of dense code, defining 109 exported
shell functions and zero aliases (yes, you may disagree with my
choice of functions over aliases. Feel free.)
3. Just ignore the whole issue and put everything everywhere.
Of the three methods, #2 has given me the most long-term stability.
What I'd like to see is something like this automated in bash. To steal
a concept from zsh and grow it a bit, I'd like to see a /etc/bash_env
and ~/.bash_env searched for and loaded by all bash invocations at startup
time BUT only if they've never been run before. With this, one can
let the .bashrc and login/profile files go back to what they should
be, and give people cleaner setups all around. As a suggested method,
adding a new var to SHELLOPTS to detect past execution of /etc/bash_env
and ~/.bashenv would work very nicely. Or environment variables
SYS_BASHENV and USR_BASHENV could be set.
IMHO this feature set would make life easier on system admins and users
alike. I'm curious as to others' opinions, and am certainly willing to
modify mine.
Best,
Steve Simmons
_______________________________________________
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
