Unfortunately, that is how it works.

I think you are making an assumption that 'scp' means 'cp over ssh'.
You think it should therefore work maximum like cp.  But it doesn't.
It has hundreds of ways it doesn't work like cp.  It is totally
different code.  It is just a 20 year mangle of the old CSRG rcp code.

You need to think of "scp" meaning "secure file copy" not
"ssh version of cp(1)".

You want us to change that behaviour?  I hope you understand that
changing the behaviour will break scripts, and the things people
type.  You might immediately think the consequences are irrelevant,
but 20 years of patterning tends to be heavy.

So the behaviour cannot be changed!  If you read the code, you'll see
how it iterates it's copying method over each of the source arguments,
to the target.  "scp host1:a host2:b c/".  This is how it worked *since
day one* as rcp, and as a result in scp.

So if you are just expressing surprise, I don't understand where it
comes from.  scp is not cp.  It's just 3 letters hinting that it is
somewhat like cp, but you are the only one making the assumption about
which specific cp behaviours you expect here.

People should really use rsync (which has it's own oddities), and really
openrsync should get some love and become a 100% compatible and viable
replacement that works the same.  Not that this can plausibly result in
the deletion of scp, tho.

Jan Stary <h...@stare.cz> wrote:

> This is current/amd64.
> 
> When copying multiple files from a remote host using scp(1)
> into a local directory that does not exist, or to local file,
> the result is that the last copied file wins.
> 
> For example, with file1 and file2 at host,
> and /tmp/nonexistent not existing at the destination,
> 
>       scp host:file* /tmp/nonexistent
> 
> will result in /tmp/nonexistent being a copy of file2
> and file1 being nowhere.
> 
> In case /tmp/nonexistent exists and is a file,
> the same happens.
> 
> In case /tmp/nonexistent exists and is a dir,
> both file1 and file2 get copied there, as with cp(1).
> 
> Is this behaviour intended?
> 
> Reading the output of 'scp -v' I see
> 
>       Sending command: scp -v -f file*
> 
> Reading the scp(1) manpage and the getopt() in scp.c,
> i see the undocummented -d -f options; with -d,
> scp exists immediately with
> 
>        /tmp/nonexistent: No such file or directory
>        /tmp/nonexistent: Not a directory
> 
> respectively; but it seems strange that the user has to
> explicitly say "I am copying multiple files into a directory",
> as opposed cp(1) doing that automatically.
> 
> Jan
> 

Reply via email to