On Fri, 2009-08-21 at 15:50 +1000, James Robertson wrote: > I am running the following command to update the line as follows: > ssh root@xxxxxxxxxxxxxxxxxx "sed -i 's/$GREP -Fi smtp/$GREP -Fi smtp | > $SORT -u/' /usr/local/bin/script.sh" Hypothesis: Your variables are all expanded to empty strings. You use single quotes to protect the command you give sed but these single quotes are meaningless *on the local side* because you put them inside double quotes. (In other word, the single quotes inside the double quotes have no special shell meaning on the local side.) When you issue the command, your local shell interprets it as: arg 0 = ssh arg 1 = root@xxxxxxxxxxxxxxxxxx arg 2 = sed -i 's/ -Fi smtp/ -Fi smtp | -u/' /usr/local/bin/script.sh arg 2 is what the shell on the remote side executes. You still get a substitution because as it so happens if $GREP is removed you still get a match! Execute the following and you'll see what happens to your variables: $ ssh root@xxxxxxxxxxxxxxxxxx "echo 's/$GREP -Fi smtp/$GREP -Fi smtp | $SORT -u/'" > This command works fine when running it on the command line directly. Presumably this is what you run: $ sed -i 's/$GREP -Fi smtp/$GREP -Fi smtp | $SORT -u/' /usr/local/bin/script.sh That's not a problem because there are no double quotes to mess up the protection which single quotes provide. Notice the difference of output between this: $ echo 's/$GREP -Fi smtp/$GREP -Fi smtp | $SORT -u/' and this: $ bash -c "echo 's/$GREP -Fi smtp/$GREP -Fi smtp | $SORT -u/'" > Could I be missing something or perhaps this is a bug? No bug. Switch the quotes form single to double and vice-versa and use backslash in the double quotes to prevent variable expansion. Example: $ bash -c 'echo "s/\$GREP -Fi smtp/\$GREP -Fi smtp | \$SORT -u/"' Good luck, Louis
