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? 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 http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=ssh&submit=Search%21&idxname=bug-bash&max=10&result=normal&sort=date%3Aearly 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 <[EMAIL PROTECTED]> - 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)
