Re: .bashrc is not sourced after ssh -t (but is sourced if -t isn't used)

[Chet Ramey]

Vincent Lefevre wrote:
> On 2007-12-05 22:30:45 -0500, Chet Ramey wrote:
>> Vincent Lefevre wrote:
>>> My main complaint is that bash behaves differently when one uses
>>> "ssh <host> <cmd>" and "ssh -t <host> <cmd>". Something needs to
>>> be done to make these commands consistent.
>> Such a mechanism is available to you: rebuild after enabling
>> SSH_SOURCE_BASHRC.
> 
> Why not having the converse by default to make this consistent, i.e.
> a default that would never source the init files for non-interactive
> shells?

That is the nominal default, but it's an imperfect world.  There's
Posix and $ENV, with $BASH_ENV for non-posix uses, user demand for
shells with argv[0][0] == '-' to read login shell startup files
regardless of whether or not the shell is interactive, and the
demand to have a shell run by rshd (or eventually sshd) read .bashrc
so $PATH can be set.

> 
> Otherwise the man page should make clear that there's a difference
> between "ssh <host> <cmd>" and "ssh -t <host> <cmd>".

The man page doesn't care.  The man page needs to say (and will)
that bash attempts to determine whether or not stdin is a network
connection and reads .bashrc in this case.

Interested users will make the intuitive leap.

>   http://lists.gnu.org/archive/html/bug-bash/2005-06/msg00042.html
> 
> | Next, if bash can't determine that its standard input is a socket or other
> | network connection, it won't try to source any bashrc file.  This prevents
> | the same code from executing when the right conditions are met but standard
> | input is a pipe, as when invoked by `make'.
> 
> Of course, relying on SSH_CLIENT only would be a bug (you probably need
> to check SHLVL too). Debian's bash version, which has SSH_SOURCE_BASHRC
> enabled, doesn't seem to have any problem when I run "make" on some
> project, after setting "SHELL = /bin/bash" in the Makefile and adding
> "echo bashrc >&2" at the beginning of my .bashrc file.

Here's the problem:  consider a user who runs a shell that doesn't
understand $SHLVL in the same way bash does (they do exist).  They ssh
to a system with bash modified with SSH_SOURCE_BASHRC enabled.  Every
time they run, explicitly (unlikely) or via some other agent (more
likely), `bash -c command', their .bashrc file, if it exists, will be
read, as will the system /etc/bashrc if that's been enabled.  This will
lead to some really obscure bug reports.  It's happened.

This is the problem that unsetting SSH_CLIENT and SSH2_CLIENT was
intended to solve.  You can do things with SHLVL, and bash does, but
that's an imperfect solution.  Users can and do modify it, and it gets
reset if it gets removed from the environment somewhere along the way.

I'd rather have bash do what it does.

If you're interested in having things done the other way, as Debian and
some others are, then there is a knob you can twist to make that happen:
SSH_SOURCE_BASHRC.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                       Live Strong.  No day but today.
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/