<> == ssh eats my word boundaries! I can't do ssh remotehost make CFLAGS="-g -O"! == [[http://www.openssh.org/|ssh]] emulates the behavior of the Unix remote shell command (`rsh` or `remsh`), including this bug. There are a few ways to work around it, depending on exactly what you need. First, here is a full illustration of the problem: {{{ ~$ ~/bin/args make CFLAGS="-g -O" 2 args: ~$ ssh localhost ~/bin/args make CFLAGS="-g -O" Password: 3 args: <-O> }}} What's happening is the command and its arguments are being smashed together into a string on the client side, then shoved through the ssh connection to the server side, where that string is handed to your shell as an argument for re-parsing. This is not what we want. === Manual requoting === The simplest workaround is to mash everything together into a single argument, and manually add quotes in just the right places, until we get it to work. {{{ ~$ ssh localhost '~/bin/args make CFLAGS="-g -O"' Password: 2 args: }}} The shell on the remote host will re-parse the argument, break it into [[WordSplitting|words]], and then execute it. The first problem with this approach is that it's tedious. If we already have both kinds of quotes, and lots of shell substitutions that need to be performed, then we may end up needing to rearrange quite a lot, add backslashes to protect the right things, and so on. The second problem is that it doesn't work very well if our exact command isn't known in advance -- e.g., if we're writing a WrapperScript. === Passing data on stdin instead of the command line === Another workaround is to pass the command(s) as standard input to the remote shell, rather than as an argument. This won't work in all cases; it means the command being executed on the remote system can't use stdin for any other purpose, since we're tying up stdin to send our commands. But in the cases where it ''can'' be used, it works quite well: {{{ # POSIX # Stdin will not be available for use by the remote program ssh remotehost sh <