3

I spend most of my day ssh'd into servers. I have a series of aliases/functions/scripts that allow me to type p hostname from the terminal and execute GNU screen(1) on the remote side, using the following command:

exec ssh hostname -t 'screen -RD'`

I've only recently noticed that ssh -t does not get my custom $PATH. Here's some terminal output:

adam@workstation:~:0$ sh server 'echo $PATH'
/home/adam/bin:/usr/local/bin:/bin:/usr/bin:/opt/git/bin:/opt/git/libexec/git-core
adam@workstation:~:0$ ssh server -t 'echo $PATH'
/usr/local/bin:/bin:/usr/bin
Connection to uranus.plymouth.edu closed.

My biggest problem is my custom aliases only try to execute screen, since I can't guarantee an absolute path, and my $PATH is structured so the shell should find the correct one. If my $PATH settings aren't honored, my scripts don't work. Is there a way I can use $PATH as defined by my .bashrc/.bash_profile?

I believe PermitUserEnvironment is disabled.

4 Answers 4

1

If you can change the command your aliases use, you can have the remote side create an “interactive”, “login” instance of bash (i.e. one that uses your .bashrc and .bash_profile) to run screen:

ssh server -t 'exec bash -ilc "exec screen -RD"'

If, in addition, you are not getting your normal environment (PATH, shell settings, etc.) in the shells created inside screen, you might need to tell screen to create “login” shells. Put shell -bash in your .screenrc on the remote ends, or add -s -bash to your screen invocation:

ssh server -t 'exec bash -ilc "exec screen -RDs -bash"'

This will certainly run your .bash_profile twice (once before screen, once for each shell created inside screen). Depending on how you do your PATH manipulations, this may lead to multiple copies of the same additions to your PATH (this is generally not a problem).

0

Your custom $PATH is probably set in a .bashrc that exits when running under the pseudo-tty environment of ssh -t ....

I don't have any direct experience with this, but I bet if you inspect the .bashrc you'll see it exiting if $PS1 isn't set, or [ -t 1 ] fails, or something like that, before setting the $PATH. And if you experiment, you'll probably find that ssh server 'try_that_test' and ssh server -t 'try_that_test' give different results.

Probably you can fix it by making the test more complex, to check if you're running under ssh.

2
  • My .bashrc sources .bash_profile, and the first two lines of .bash_profile export PS1 and PATH. Feb 16, 2010 at 14:39
  • Curious. Just tested on my machine and ssh localhost 'echo $PATH' and ssh localhost -t 'echo $PATH' both give me default PATHs. But ssh localhost and ssh localhost -t both give me a shell with my custom PATHs.
    – dubiousjim
    Feb 16, 2010 at 16:29
0

.bashrc and .bash_profile are only processed for interactive shells, which any shell that executes a program such as screen (or echo in the test cases) is not. Read up in the bash man page about the BASH_ENV environment variable, which can be set up to run a start script for noninteractive shells.

3
  • @Peter, yes I also thought the non-interactiveness of his shell might be responsible. But it's puzzling why he gets the $PATH changed when he does ssh server 'echo $PATH' (with no -t).
    – dubiousjim
    Feb 16, 2010 at 23:14
  • bashrc is sourced on all shells, both interactive and non-interactive. Sep 23, 2010 at 18:10
  • @Rich Homolka: No, I'm afraid you're wrong. Sep 24, 2010 at 22:33
0

You may want to use ~/.ssh/rc or ~/.ssh/environment as well. See the sshd(8) man page.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .