Feature semi-request about bash initialization

[Steve Simmons]

(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