There is little you can do if you can't change the command. The
~/.bashrc file should be getting processed during this command execution.
What might be happening is that you have a conditional exit statement in .bashrc , usually right near the beginning, which will exit if the current shell is detected to be non-interactive ( in this case it is). Sometimes the script will check if the primary prompt variable PS1 is set; which is a common but ugly method to evaluate for an interactive vs a non-interactive shell. In this case when PS1 is not set the remainder of .bashrc is not parsed.
I would check if that is the case - use some simple debugging techniques to see if .bashrc is sourced and if it ends early (eg echo statements). You would need to modify .bashrc on the remote machine to address that, and that may break other things such as scp and sftp. Or you could just set PS1 in your remote command.
There are any number of workarounds if you can modify the remote command:
- Add the items necessary to run the script to a separate bash file. Source it directly in your command.
- Use the full paths in the command and in the remote script. I don't know what other env dependencies besides PATH you have but obviously those have to be addressed as well.
- On the remote machine populate
~/.ssh/environment with all necessary environmental variables, aliases, functions etc. Modify the ssh config file
/etc/ssh/shhd to make sure that the setting
PermitUserEnvironmentis enabled; otherwise this won't work.
- Add the environmental variable settings to the command, eg
PATH ensures that its the remote
version we are adding to, preventing expansion prior to sending the
If none of this will work please describe your constraints in more detail.