According to the FAQ: "It is slightly trickier in rsync because rsync sends a command line to the remote system to launch the peer copy of rsync. The command line is interpreted by the remote shell and thus the spaces need to arrive on the remote system escaped so that the shell doesn't split such filenames into multiple arguments." I would argue that the Principle of Least Surprise dictates that rsync should handle any quoting needed by the remote system itself rather than make the user do it. If that is not feasible because of unknown quoting requirements on the remote system then perhaps the protocol should be enhanced so that the command line that is passed to the shell is very simple, like "rsync --server-enhanced" and all the "command-line arguments" are actually passed as input to that command as part of the protocol.
Rsync users exploit this space-splitting behavior to request multiple files from a remote server, so it cannot be changed at this late date without causing incompatibilities. One work around is to use the --files-from option. For instance, instead of running this: rsync -av remote:'/Some\ Path/To/Some\ File.txt' /dest you could run this: echo '/Some Path/To/Some File.txt' | rsync -av --files-from=- --no-relative remote:/ /dest It's a little more complicated, but it does work with filesnames that contain spaces.
problem with this solution is that having / at the end of the file in the files-from file doesn't work anymore
(In reply to comment #2) > problem with this solution is that having / at the end of the file in the > files-from file doesn't work anymore I'm not sure what you mean. A trailing slash has the same meaning in a file-from line when as it does on the command-line: rsync -av dir/ /var/tmp/newdir/ echo dir/ | rsync -arv --files-from=- --no-relative . /var/tmp/newdir/ Those behave exactly the same way. Perhaps you missed the --no-relative part?