mmarkk@ubuntu:~$ scp host.ru:/home/mmarkk/some\ dir/file.ext . mmarkk@host.ru's password: scp: /home/mmarkk/some: No such file or directory scp: dir/file.ext: No such file or directory It is able to copy to local dir with space. but mmarkk@ubuntu:~$ scp /etc/passwd host.ru:/mnt/rw_disc/qwe\ qwe/ mmarkk@host.ru's password: scp: ambiguous target
Actually you can, but you need to double-quote the argument since it gets processed twice: once by the local shell and once by the remote shell. Both of these work: $ scp "localhost:/tmp/foo\ bar/baz" baz $ scp localhost:/tmp/foo\\\ bar/baz baz Your local example works because it's only processed once by the local shell.
I think, that when issuing command on remote shell, scp SHOULD escape strings.
If not, it is security vulnerability - suppose one have automatic scp commands on some server. Specifying bad file name may cause executing commands or accessing files on remote side. double-quoting may cause compatibility problems in future, when this bug will be eliminated.
(In reply to comment #2) > I think, that when issuing command on remote shell, scp SHOULD escape > strings. You can't reliably do this: there's no way for scp to know what the remote shell is and thus what its escaping rules are. There's no guarantee it has the same rules as the local shell. (In reply to comment #3) > If not, it is security vulnerability - suppose one have automatic scp > commands on some server. Specifying bad file name may cause executing > commands or accessing files on remote side. If the (restricted) shell you're using allows executing commands based on the content of the filenames then you have a problem with either the shell or its config. Also, relying on client-side escaping as a security measure is worthless even if you could do it reliably, which you can't. > double-quoting may cause compatibility problems in future, when this > bug will be eliminated. This is fundamentally unfixable within the scp "protocol", such as it is. If this bugs you then use sftp instead since the filename are encoded in a defined way within the protocol and not subject to the vagaries of shell processing. See http://www.openssh.com/faq.html#2.10
Sorry, but as per the FAQ we won't be changing this.
Move resolved bugs to CLOSED after 5.7 release