Consider the file /tmp/ap.sh which simply prints out all the arguments to it:

  #! /bin/sh

  while [ $# -ge 1 ]; do
	  echo "arg: $1"
      shift
  done

If I create a C file ex_local.c:

  #include <unistd.h>

  int main(int argc, char** argv) {
      execlp(argv[1], argv[1], "a", "a'b", NULL);
      return 0;
  }

and then compile and run it, the arguments passed to it are printed out:

  $ ex_local /tmp/ap.sh
  a
  a'b
  $

which is correct. If I have this C file ex_ssh.c:

  #include <unistd.h>

  int main(int argc, char** argv) {
      execlp("/usr/bin/ssh", "/usr/bin/ssh", argv[1], argv[2], "a", "a'b", NULL);
      return 0;
  }

and run it:

  $ ex_ssh somehost.com /tmp/ap.sh
  zsh:1: unmatched '

then /tmp/ap.sh isn't even executed on the remote machine. This surprised me, because (perhaps naively), I expected parameters passed to a command to work identically whether that command is local or run via ssh. Just to show that it isn't the fault of zsh on the remote machine, other shells show the same problem even with a simpler version of the escaping problem:

  $ echo ls \'
  '
  $ ssh someotherhost.com echo ls \'
  bash: -c: line 0: unexpected EOF while looking for matching `''
  bash: -c: line 1: syntax error: unexpected end of file

The basic problem, as far as I can tell, is that ssh is passing arguments as unprotected strings to the remote shell to execute the command. In essence, "funny" characters (e.g. ') are being reevaluated remotely, even though they would not locally.

Assuming I have got the right end of the stick so far (which is no by no means guaranteed), it's not obvious to me what the best behaviour should be. When a user executes a command via ssh, there is a soft notion that a login shell will be executed, with the users normal customisation, before the command is executed. I presume this is what ssh is doing at the moment, and where the parameter problem occurs. The only way I can see for arguments to be passed reliably is for ssh to invoke a middle-man command which then execv's with precisely the parameters passed to ssh itself. This might be rather heavy-weight for most uses, and will break backwards compatibility (some people are bound to have inadvertently come to rely on the current behaviour): perhaps it could be enabled via an optional switch?