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'
adam@workstation:~:0$ ssh server -t 'echo $PATH'
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.


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


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.

  • My .bashrc sources .bash_profile, and the first two lines of .bash_profile export PS1 and PATH. – Annika Backstrom Feb 16 '10 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 '10 at 16:29

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

  • @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 '10 at 23:14
  • bashrc is sourced on all shells, both interactive and non-interactive. – Rich Homolka Sep 23 '10 at 18:10
  • @Rich Homolka: No, I'm afraid you're wrong. – Peter Eisentraut Sep 24 '10 at 22:33

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.