Re: scp protocol error on multiple file copy?

[mlelstv%serpens.de@localhost (Michael van Elst)]

jdbaker%consolidated.net@localhost ("John D. Baker") writes:

>On the remote, it invokes 'scp' with an undocumented "-f" (lowercase
>"f") switch:

>  debug1: Sending command: scp -v -p -f /path/to/@(sets/@([bem*|text.tgz)|kernel/netbsd-CUSTOM.gz)

>passing it the path/fileglob given on the local host.


Actually that is passed to the shell first, if the shell doesn't interpret
the globbing, it passes it then unchanged to the command.

The '-f' and the '-t' are the hidden flags that tell the scp command to
serve the operation on the remote machine, depending on direction (from,to):

% scp fud:'@(raid0|raid1).label' .
protocol error: filename does not match request

With -v you see that the remote machine (with ksh) correctly globs that pattern
and tries to send the files:

Sink: C0644 894 raid0.label
Sending file modes: C0644 894 raid0.label
protocol error: filename does not match request
Sending file modes: C0644 890 raid1.label

But the local scp client tries to parse the answers and since it doesn't
understand the ksh pattern, it rejects the files sent. The -T flag skips
that pattern check.

% scp -T fud:'@(raid0|raid1).label' .
raid0.label                                   100%  894   266.4KB/s   0.9KB/s  
raid1.label                                   100%  890   305.3KB/s   0.9KB/s  

Unlike the globbing on the remote side, the local check doesn't use the
shell to interpret the pattern. Instead scp itself splits braced sequences
like '{a,b,...}' and calls fnmatch() to handle the parts.

scp is a hack.

-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."