Re: SSH file transfer doesn't handle filenames with blanks

[Brian May <bam@debian.org>]

>>>>> "Wouter" == Wouter Verhelst <wouter@grep.be> writes:

    >> To my great amazement, scp refused to copy filenames with
    >> blanks or worse characters (like an ampersand '&') in it.  Is
    >> that a bug in SSH?
    >> 
    >> $ scp 'localhost:archiv/music/Sonata Arctica/Silence/12_Wolf &
    >> Raven.ogg'

    Wouter> Not really; it's a horrible quoting issue. When quoting
    Wouter> filenames with scp, you have to quote them twice, e.g.:

You can use this horrible quoting to type something like:

scp 'localhost:archiv/music/Sonata Arctica/Silence/1*.ogg' .

ie. expansion of wild card characters is possible on the remote host.

I am not sure if sftp has similar command line functionality, I
haven't used it often.

Also, it is perhaps worth noting that rsync over ssh seems to have
exactly the same quoting issues:

>rsync -essh 'snoopy:tmp/a & b& c' .
zsh: command not found: b
zsh: command not found: c
rsync: connection unexpectedly closed (4 bytes read so far)
rsync error: error in rsync protocol data stream (code 12) at io.c(190)
rsync: connection unexpectedly closed (8 bytes read so far)
rsync error: error in rsync protocol data stream (code 12) at io.c(190)

The issue, I suspect, is that rsync and scp passes the entire string
"snoopy:tmp/a & b & c" to sh on the remote computer (for expansion)
which treats "&" and " " (not to mention others) as special
characters. IMHO, the string shouldn't be passed to sh again, as sh
reinterprets the parameter boundaries in the string, when the
parameter boundaries were already known.
-- 
Brian May <bam@debian.org>