Re: [Help-bash] The execution of /etc/bash.bashrc and ~/.bashrc for non interactive shells

[Chet Ramey]

On 3/30/17 10:34 AM, Greg Wooledge wrote:

> The decision to use bashrc (etc.) when bash is invoked interactively by
> ssh goes back many years.  Here are some past threads talking about it:

(We're not talking about interactive shells here.)

> 
> https://lists.gnu.org/archive/html/bug-bash/2007-12/msg00000.html
> https://lists.gnu.org/archive/html/bug-bash/2008-10/msg00051.html

The discussions and bug reports go back years before that, to the late
1990s.  The original request was for bash to run the startup files when
invoked by ssh because that was the only way to, for example, set PATH,
and bash had supported that when using rsh for many years. (Using
something like ssh's .environment was deemed inconvenient.)  The first
complaint I found about that dates from 1997.  Someone contributed a
patch that used SSH_CLIENT to detect whether or not bash was being run
by ssh, so it got changed.

There were a bunch of startup files that produced  output on stdout,
which messed up scp, but people got  past that.

Bash used the presence of the SSH_CLIENT or SSH2_CLIENT variables to
detect whether or not it was being run by ssh.  However, leaving those
in the environment meant that other non-interactive shells run as part
of the session would see them and run the startup files (like the `bash
-c' jobs run by `make'), so bash made them local.

That led to a firestorm of complaints about modifying the environment,
including golden comments characterizing the bash behavior as "pathetic",
which resulted in the included comment:

>      /*
>       * 24 October 2001
>       *
>       * I'm tired of the arguing and bug reports.  Bash now leaves SSH_CLIENT
>       * and SSH2_CLIENT alone.  I'm going to rely on the shell_level check in
>       * isnetconn() to avoid running the startup files more often than wanted.
>       * That will, of course, only work if the user's login shell is bash, so
>       * I've made that behavior conditional on SSH_SOURCE_BASHRC being defined
>       * in config-top.h.
>       */

And so here we are.  Bash uses the shell_level check and makes sure that
it's 1 before running the startup files when using `bash -c'. I'm sure
you can see the problem with this: it really works well only when a user's
login shell is bash. If someone logs into a machine using ssh, their login
shell is not bash, and they eventually at some point run `bash -c command',
the bash startup files, including /etc/bash.bashrc, will be executed.  As
the comment says, that's why the behavior has to be specifically enabled.

There were still plenty of complaints about bash not behaving "as
documented" when SSH_SOURCE_BASHRC is not defined, like in the threads
Greg posted.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/