As the title says, I want to modify environment variables on a remote server using 'ssh'.

My first attempt was:

$ ssh mysvr -l sikaiwei "getId=$ORANGE; echo $ORANGE; ORANGE=$((ORANGE+1)); echo $ORANGE; echo 'getId is '+$getId;"

At first, I didn't define $ORANGE on the server host, but defined $ORANGE as "1" on the client, and I got:

getId is +

Note that the command is picking up the client's value of $ORANGE, and the update (ORANGE+1) isn't happening.

Then I removed the $ORANGE definition on the client host, and defined $ORANGE on the server by putting a command into my .bash_profile. But

$ ssh mysvr -l sikaiwei "getId=$ORANGE; echo $ORANGE; ORANGE=$((ORANGE+1)); echo $ORANGE; echo 'getId is '+$getId;"

resulted in

getId is +

It can't print the value of $ORANGE that I attempted to initialize on the server host! Then I tried this:

$ ssh mysvr -l sikaiwei ". .profile; getId=$ORANGE; echo $ORANGE; ORANGE=$((ORANGE+1)); echo $ORANGE; echo 'getId is '+$getId;"

getId is +

It still doesn't work.

I tried using '..' (single quotes) instead ".." (double quotes) as you said, but it prints nothing...

$ ssh myth@mysvr 'echo orangeis $ORANGE'

I want to print

 getId=1; echo 1; ORANGE=2; echo 2; …

instead of

 getId=; echo ; ORANGE=1; echo ; …

So how can I use the $ORANGE value from the server host instead of the client value?

My server machine runs Windows, but I installed Cygwin. My client machine runs Linux.

Edit: I found part of the problem: I was setting $ORANGE in ~/.bash_profile on the server host, and I can get value of $ORANGE using "echo $ORANGE" in an interactive shell (Cygwin), but this wasn't affecting ssh command strings. For example, I get nothing when my client host uses

$ ssh sikaiwei@mysvr 'echo orange is $ORANGE'
orange is

Like that, I don't get the value of $ORANGE that I do in a session on the server. The . .profile that I added didn't help. But if I

$ ssh sikaiwei@mysvr '. ~/.bash_profile;echo orange is $ORANGE'
orange is 4

I got the value!

Oh, did I forget to mention: I want these variables on the server to be persistent. In other words, if I execute an ssh command that changes the value of $ORANGE from 4 to 42, then I want $ORANGE to be 42 when I do another ssh command.

  • You say, “I … defined $ORANGE on the server host.” How? What did you do to define ORANGE on the server? – Scott Dec 19 '13 at 23:44
  • Server machine is mine.It run Windows,but installed Cygwin.I definde ORANGE in .bash_profile on the Server. – orange Dec 20 '13 at 1:15
  • Are you sure .bash_profile gets processed for ssh jobs? Can you check by putting echo $ORANGE into .bash_profile? – Scott Dec 20 '13 at 1:48
  • My fault...First I use . ~/.bash_profile,then I can use the variable defined in ~/.bash_profile – orange Dec 20 '13 at 8:35
  • Well, the bash(1) man page says that bash reads .bash_profile only if it is an interactive shell, or if it is invoked with the --login option. If you invoke ssh with a command string argument, the shell will not be considered interactive, and so .bash_profile will not be read automatically. – Scott Dec 20 '13 at 22:30

The problem is that shell variables (of which environment variables are a subset or variant) that are quoted in double quotes ("…") are processed immediately.  So, if ORANGE is set to 1 locally, as you report having done in your first experiment, and you type

… ssh … "getId=$ORANGE; echo $ORANGE; ORANGE=$((ORANGE+1)); echo $ORANGE; …"

ssh is getting

getId=1; echo 1; ORANGE=2; echo 1; …

And, if ORANGE is not set locally, as you report having done in your second experiment, ssh is getting

getId=; echo ; ORANGE=1; echo ; …

To send the command to the remote system as you typed it, complete with dollar signs, so it will be processed by the shell on the remote system, wrap it in single quotes ('…').

For example, if you say

… ssh … 'echo orangeis $ORANGE'

then ssh is seeing

echo orangeis $ORANGE

and sending that to the remote system.  This causes the shell on the remote system to output


(with a space at the end) because you haven’t done anything to give ORANGE a value (or, if you did something, it didn’t work).

You say

I want to print

  getId=1; echo 1; ORANGE=2; echo 1; …

which is clearly not what you mean.  If you mean that you want to print


try something like

… ssh … 'ORANGE=1; getId="$ORANGE"; echo "getId=$getId"; echo $ORANGE; ORANGE=$((ORANGE+1)); echo $ORANGE; …"

You have refined your question (in the comments) to indicate that you want to be able to manipulate shell/environment variables on the remote server and have changed values persist from one session to another. To do this, you will need to explicitly store the values somewhere (on the server). A simple way to save a value is to execute

echo "$ORANGE" > orange.txt

You can then retrieve this value with a command like

read ORANGE < orange.txt


ORANGE=$(cat orange.txt)

A slightly different approach would be to save your value with

echo "ORANGE=\"$ORANGE\"" > value.sh

and then retrieve it with

. value.sh

IMNSHO, it doesn’t particularly make sense to use your .bash_profile to store these values if you are going to modify them on a frequent basis.

Note that you should use >> to append to a file and >| to overwrite an existing file.

  • I reedit it.If like last line of your answer ,when a new ssh chonnection start ,it can't get the value of ORANGE defined at first ssh connection,So I want to defined a System variable which every ssh connection can access and modify dynamics.Look at the end of question ,I use '. .~/.bash_profile' ,then get the value. – orange Dec 20 '13 at 5:54
  • Shell variables are transient. If you type PURPLE=17 or ZAPHOD=42 to a shell, and then logout and login again, those values will be gone. Similarly, separate ssh sessions are separate (e.g., if you do ssh cd /foo and then do another ssh command, you’ll be back in your home directory – shell state isn’t preserved across sessions). But see my answer for more information. – Scott Dec 20 '13 at 22:29
  • Sorry for waste your time to reedit my quedtion and answer it...And thanks a lot!The answer is my want! – orange Dec 21 '13 at 2:38

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.