Re: .bashrc is not sourced after ssh -t (but is sourced if -t isn't used)
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=sshsubmit=Search%21idxname=bug-bashmax=10result=normalsort=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)
Re: .bashrc is not sourced after ssh -t (but is sourced if -t isn't used)
Vincent Lefevre wrote: 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. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: .bashrc is not sourced after ssh -t (but is sourced if -t isn't used)
On 2007-12-05 14:31:33 -0500, Chet Ramey wrote: 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? -- 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)
Re: .bashrc is not sourced after ssh -t (but is sourced if -t isn't used)
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? -- 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)
Re: .bashrc is not sourced after ssh -t (but is sourced if -t isn't used)
Vincent Lefevre wrote: 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). Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
.bashrc is not sourced after ssh -t (but is sourced if -t isn't used)
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. According to the bash man page, (1) is correct and (2) is incorrect (sshd is the remote shell daemon nowadays). But according to the CHANGES and COMPAT files, this is the converse. Note that Debian doesn't have this problem, probably because SSH_SOURCE_BASHRC is uncommented (see README.Debian.gz). Concerning OpenSUSE, I had reported a bug here: https://bugzilla.novell.com/show_bug.cgi?id=345570 -- 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)
Re: .bashrc is not sourced after ssh -t (but is sourced if -t isn't used)
Vincent Lefevre wrote: 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[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
