The information below is valid if you
ssh into the machine and then run your command which starts a login shell:
If you are trying to access the variable directly from the
ssh command (
ssh root@ip echo $XXXX_LICENSE_FILE) then you are starting a non-login, non-interactive shell in which case neither
~/.bashrc are read. From the
bash man page:
When bash is started non-interactively, to run a shell script,
for example, it looks for the variable BASH_ENV in the envi‐
ronment, expands its value if it appears there, and uses the
expanded value as the name of a file to read and execute.
Bash behaves as if the following command were executed:
if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi
but the value of the PATH variable is not used to search for
the file name.
The easiest workaround would be to simply declare the variable along with the
ssh command. For this to work, you need to add this line to the remote
Then run this from the local machine:
XXXX_LICENSE_FILE=/etc/xxxx.lic && ssh -nq -t -t -t root@$ip /etc/init.d/xxxx.rc start
The problem here is the difference between login and interactive shells. See here for a nice summary.
~/.bashrc is only read when starting an interactive (non-login) shell. When you
sshinto a remote machine, you are running a login shell so
~/.profile (in that order) are read instead. You can check this by running
bash after loging on to the remote server, that will start an interactive shell,
~/.bashrc will be read and your environment variable will be set.
To fix this, define the variable in your
~/.bash_profile instead of
I am assuming that you are setting the variable in the remote
.bashrc, not your local one. If you want to export a local variable over
ssh, have a look at the link posted by Frederik Deweerdt. The easiest way would be to include your variable in the invocation of
ssh -nq -t root@ip "FOO=foo BAR=bar"