> No. sshd does not run the users ~/.bash* or ~/.tcsh* files when
> executing a remote command. Those files are only run if the user is
> logging in and starting an interactive shell. This has come up many
> times on the list... it seems to bite many Mac users (myself
> included).
>
> Depending on what your default shell is, you need to modify (or add)
> the PATH variable in the following files (taken from an Xserve at
> work):
>
> /etc/bashrc:export PATH=$PATH:/usr/local/bin
> /etc/csh.cshrc: setenv PATH "$PATH"":/usr/local/bin"
> /etc/csh.login:setenv PATH
> "/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin"
This isn't exactly the whole story...
When sshd executes a command, it does so using the user's default
shell, run as that user. This can be easily verified because the the
error when the path variable is incorrectly set is:
'tcsh: svnserve: Command not found.'
or
'bash: svnserve: Command not found.'
depending on the user's shell.
So now the question is which dotfiles do bash or tcsh run when invoked
non-interactively (which is how sshd invokes them when it uses the
shell to execute a command). A quick trip to the bash and tcsh man
pages answers this question:
man tcsh:
> Non-login shells read only /etc/csh.cshrc and ~/.tcshrc or ~/.cshrc on
> startup.
The bash man page is less clear, but it appears that .bashrc is read
when rshd (or, presumably, sshd) executes bash:
> Bash attempts to determine when it is being run by the remote shell
> daemon, usually rshd. If bash determines it is being run by rshd, it
> reads and executes commands from ~/.bashrc, if that file exists and is
> readable.
So in either case, the .bashrc or .tcshrc file should be invoked,
provided that sshd is in fact running the command from a shell (I think
there are ways to configure it to not do so, but they are not common,
and then in that case the error message would be 'sshd: svnserve:
command not found' or something similar, not 'tcsh:...'.)
Likewise, etc/bashrc and etc/csh.cshrc get read in either case.
The files that emphatically *do not* get read are /etc/profile,
~/.profile, /etc/csh.login, and ~/.login.
So if the path is set in the any of these files, problems arise.
The reason this bites Mac users particularly is that many have
installed subverison via fink, which puts it in /sw/bin. This needs a
special PATH entry, which sometimes ends up in a .login or .profile
file.
Now, we can easily test the claim that (at least with tcsh), sshd does
in fact invoke tcsh in such a manner that it reads the .tcshrc file in
my home directory:
1) Note that I've installed svn via fink, so it lives in /sw/bin. The
only place that '/sw/bin' is added to my path is in a single line my
~/.tchsrc on the machine that is the subversion server. (I grep -r'd
etc/* for any mention of /sw/, and there was none.)
2) With this single line intact in the ~/.tchsrc, something like: 'svn
ls svn+ssh://host/repository' works.
3) When I comment out the single line in the .tcshrc file that adds
/sw/bin to the path, then the same command fails with the message
'tcsh: svnserve: Command not found.'
4) Restoring the line restores svn functionality.
ergo, sshd is in fact invoking tcsh in such a manner that it reads my
.tcshrc file.
Zach Pincus
Department of Biochemistry and Program in Biomedical Informatics
Stanford University School of Medicine
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 25 08:11:43 2005