I can\'t seem to set a new $PATH such that it is used when executing commands via ssh user@host command
. I have tried adding export PATH=$PATH:$HOME/new_
ssh documentation says:
If command is specified, it is executed on the remote host instead of a login shell.
which is why adding to the bashrc files doesn't work. you do however have the following options:
If the PermitUserEnvironment
option is set in the sshd config, you can add your PATH setting to ~/.ssh/environment
ssh remotemachine 'bash -l -c "somecommand"'
You can always say:
ssh remotemachine 'export PATH=wedontneedastinkingpath; echo $PATH'
Just had the same problem myself, solved it with:
ssh user@remotehost PATH=\$HOME/bin:\$PATH\; remote-command
As grawity said, ~/.bashrc is what you want, since it is sourced by non-interactive non-login shells.
I expect the problem you're having has to do with the default Ubuntu ~/.bashrc file. It usually starts with something like this:
# If not running interactively, don't do anything
[ -z "$PS1" ] && return
You want to put anything for non-interactive shells before this line.
Do you have an ~/.bash_login
or ~/.bash_profile
?
Bash in interactive mode checks for these files, and uses the first existing one, in this order:
~/.bash_profile
~/.bash_login
~/.profile
So if you have an ~/.bash_profile
, then whatever changes you do to ~/.profile
will be left unseen.
Bash in non-interactive mode sometimes reads the file ~/.bashrc
(which is also often source'd from the interactive scripts.) By "sometimes" I mean that it is distribution-dependent: quite oddly, there is a compile-time option for enabling this. Debian enables the ~/.bashrc
reading, while e.g. Arch does not.
ssh
seems to be using the non-interactive mode, so ~/.bashrc
should be enough. When having problems like this, I usually add a few echo's to see what files are being run.
In addition to @signpolyma answer, you will have to add your export before these lines
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac