Re: .bashrc is not sourced after ssh -t (but is sourced if -t isn't used)
Chet Ramey
> The following has been tried on OpenSUSE 10.2 and Mac OS X 10.4.11.
>
> When run by sshd, bash doesn't behave consistently:
> 1. bash sources the init files when one uses "ssh <host> <cmd>".
> 2. bash doesn't do that when one uses "ssh -t <host> <cmd>".
Bash does 1 if (and only if) it can detect it's being run with its
stdin connected to a socket. `ssh -t' intentionally defeats that.
There is other checking that SSH_SOURCE_BASHRC enables: looking for
SSH_CLIENT or SSH2_CLIENT.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Live Strong. No day but today.
Chet Ramey, ITS, CWRU ch...@case.edu http://cnswww.cns.cwru.edu/~chet/
Vincent Lefevre
> Bash does 1 if (and only if) it can detect it's being run with its
> stdin connected to a socket. `ssh -t' intentionally defeats that.
> There is other checking that SSH_SOURCE_BASHRC enables: looking for
> SSH_CLIENT or SSH2_CLIENT.
So, will SSH_SOURCE_BASHRC be reenabled by default so that bash
behaves as documented?
--
Vincent Lefèvre <vin...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Chet Ramey
> On 2007-12-04 22:56:21 -0500, Chet Ramey wrote:
>> Bash does 1 if (and only if) it can detect it's being run with its
>> stdin connected to a socket. `ssh -t' intentionally defeats that.
>> There is other checking that SSH_SOURCE_BASHRC enables: looking for
>> SSH_CLIENT or SSH2_CLIENT.
>
> So, will SSH_SOURCE_BASHRC be reenabled by default so that bash
> behaves as documented?
No. sshd is not the `remote shell daemon'. The remote shell daemon
the man page speaks of runs on port 514 and is named either `rshd'
or `remshd'. Bash behaves exactly as documented.
I don't think you looked up the acrimonious discussion that preceded
my turning off the special handling of SSH_CLIENT and SSH2_CLIENT. I
won't be making that the default again.
Vincent Lefevre
> No. sshd is not the `remote shell daemon'. The remote shell daemon
> the man page speaks of runs on port 514 and is named either `rshd'
> or `remshd'.
The sshd man page says:
sshd (OpenSSH Daemon) is the daemon program for ssh(1). Together these
programs replace rlogin and rsh,
^^^^^^^
which can be interpreted as being the remote shell daemon. I think
that the bash man page should be clarified.
> Bash behaves exactly as documented.
It doesn't: If sshd is not regarded as the remote shell daemon, then
the bash man page implies that with "ssh <host> <cmd>", bash does *not*
run the init files. But when testing this on various machines, one can
see that bash really runs the init files.
> I don't think you looked up the acrimonious discussion that preceded
> my turning off the special handling of SSH_CLIENT and SSH2_CLIENT. I
> won't be making that the default again.
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.
BTW, where can this discussion be found? Could there be a reference
to this discussion in the CHANGES and COMPAT files?
Chet Ramey
> which can be interpreted as being the remote shell daemon. I think
> that the bash man page should be clarified.
I'll tighten it up some.
> 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.
> BTW, where can this discussion be found? Could there be a reference
> to this discussion in the CHANGES and COMPAT files?
Look back in the bug-bash mailing list archives. You can find the
approximate time of the change from the changelog (CWRU/changelog).
Vincent Lefevre
> 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?
Otherwise the man page should make clear that there's a difference
between "ssh <host> <cmd>" and "ssh -t <host> <cmd>".
> > BTW, where can this discussion be found? Could there be a reference
> > to this discussion in the CHANGES and COMPAT files?
>
> Look back in the bug-bash mailing list archives. You can find the
> approximate time of the change from the changelog (CWRU/changelog).
With
I could only find
http://lists.gnu.org/archive/html/bug-bash/2001-10/msg00100.html
| > Eventually I traced this to bash not passing the exported variable
| > SSH_CLIENT from its parent to its own exported environment!
|
| OK. I'm tired of arguing. The next version of bash will not do anything
| to the SSH_CLIENT or SSH2_CLIENT variables.
|
| Since this now exposes the problem that the un-export attempted to solve,
| bash will not try to figure out whether it's being run by sshd at all,
| and will not source any startup files if it is.
but I don't see any problem if SSH_CLIENT or SSH2_CLIENT is exported.
Paul Jarc replied: "What problem is that?" No answer.
I've also found:
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.
FYI, on a Debian machine (with SSH_SOURCE_BASHRC enabled and
SSH_CLIENT exported as you can see below):
courge:~> printenv SSH_CLIENT
140.77.51.8 54000 22
courge:~> grep '^echo' .bashrc
echo bashrc >&2
courge:~> cat tst
#!/bin/bash
echo SHLVL: $SHLVL
courge:~> ./tst
SHLVL: 2
You can see that "bashrc" isn't printed. And my .bashrc is run after
a ssh and ssh -t:
courge:~> ssh localhost printenv SSH_CLIENT
127.0.0.1 49248 22
Connected to courge (from 127.0.0.1)
bashrc
courge:~> ssh -t localhost printenv SSH_CLIENT
Connected to courge (from 127.0.0.1)
bashrc
127.0.0.1 54163 22
Connection to localhost closed.
Chet Ramey
> 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.