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    c...@case.edu    http://cnswww.cns.cwru.edu/~chet/

On 2007-12-04 22:56:21 -0500, Chet Ramey wrote:

So, will SSH_SOURCE_BASHRC be reenabled by default so that bash
behaves as documented?

--
Vincent Lefèvre <vinc...@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)

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.

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

On 2007-12-05 14:31:33 -0500, Chet Ramey wrote:

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.

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.

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?

--
Vincent Lefèvre <vinc...@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)

I'll tighten it up some.

Such a mechanism is available to you: rebuild after enabling
SSH_SOURCE_BASHRC.

Look back in the bug-bash mailing list archives.  You can find the
approximate time of the change from the changelog (CWRU/changelog).

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

On 2007-12-05 22:30:45 -0500, Chet Ramey wrote:

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>".

With

http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=ssh&submit=Sear...

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.

--
Vincent Lefèvre <vinc...@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)

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.

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.

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    c...@case.edu    http://cnswww.cns.cwru.edu/~chet/