tl;dr -> scp errs out if the target directory (on remote system) name has
spaces in it.

Something like:

$ scp file "RemSys:/path/that contains spaces"

Get an err msg something about "ambiguous target".

Workaround/fix is to double quote like thus:

$ scp file "RemSys:'/path/that contains spaces'"

I was able to figure this out, but it is weird. Any idea if/where/how this
problem is documented?

--
"I think I understand delicate, but why do I have to wash my hands, and
be standing in cold water when doing it?"

Kaz Kylheku <kaz@kylheku.com> in comp.lang.c

On 2022-11-30, Kenny McCormack <gazelle@shell.xmission.com> wrote:

> tl;dr -> scp errs out if the target directory (on remote system) name has
> spaces in it.

Fixed in OpenSSH 9.0:

------------------->
This release switches scp(1) from using the legacy scp/rcp protocol
to using the SFTP protocol by default.

Legacy scp/rcp performs wildcard expansion of remote filenames (e.g.
"scp host:* .") through the remote shell. This has the side effect of
requiring double quoting of shell meta-characters in file names
included on scp(1) command-lines, otherwise they could be interpreted
as shell commands on the remote side.

This creates one area of potential incompatibility: scp(1) when using
the SFTP protocol no longer requires this finicky and brittle quoting,
and attempts to use it may cause transfers to fail. We consider the
removal of the need for double-quoting shell characters in file names
to be a benefit and do not intend to introduce bug-compatibility for
legacy scp/rcp in scp(1) when using the SFTP protocol.

Another area of potential incompatibility relates to the use of remote
paths relative to other user's home directories, for example -
"scp host:~user/file /tmp". The SFTP protocol has no native way to
expand a ~user path. However, sftp-server(8) in OpenSSH 8.7 and later
support a protocol extension "expand-path@openssh.com" to support
this.

In case of incompatibility, the scp(1) client may be instructed to use
the legacy scp/rcp using the -O flag.
<-------------------

If you have at least OpenSSH 8.7:

------------------->
- scp(1): experimental support for transfers using the SFTP protocol
as a replacement for the venerable SCP/RCP protocol that it has
traditionally used. SFTP offers more predictable filename handling
and does not require expansion of glob(3) patterns via the shell
on the remote side.

SFTP support may be enabled via a temporary scp -s flag. It is
intended for SFTP to become the default transfer mode in the
near future, at which time the -s flag will be removed. The -O
flag exists to force use of the original SCP/RCP protocol for
cases where SFTP may be unavailable or incompatible.
<-------------------

--
Christian "naddy" Weisgerber naddy@mips.inka.de

Kenny McCormack <gazelle@shell.xmission.com> wrote:

> tl;dr -> scp errs out if the target directory (on remote system) name has
> spaces in it.
>
> $ scp file "RemSys:/path/that contains spaces"
>
> Get an err msg something about "ambiguous target".
>
> Workaround/fix is to double quote like thus:
>
> $ scp file "RemSys:'/path/that contains spaces'"
>
> I was able to figure this out, but it is weird.

Not really. In the first example, the shell strips the double quotes and
invokes scp with the path as one argument.

--
Now without signature.

In article <slrntofdso.gau.naddy@lorvorc.mips.inka.de>,
Christian Weisgerber <naddy@mips.inka.de> wrote:
>On 2022-11-30, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>
>> tl;dr -> scp errs out if the target directory (on remote system) name has
>> spaces in it.
>
>Fixed in OpenSSH 9.0:
>
>------------------->
>This release switches scp(1) from using the legacy scp/rcp protocol
>to using the SFTP protocol by default.
>
>Legacy scp/rcp performs wildcard expansion of remote filenames (e.g.
>"scp host:* .") through the remote shell. This has the side effect of
>requiring double quoting of shell meta-characters in file names
>included on scp(1) command-lines, otherwise they could be interpreted
>as shell commands on the remote side.

Thanks. This was a helpful, informative post.

....

> SFTP support may be enabled via a temporary scp -s flag. It is
> intended for SFTP to become the default transfer mode in the
> near future, at which time the -s flag will be removed. The -O
> flag exists to force use of the original SCP/RCP protocol for
> cases where SFTP may be unavailable or incompatible.

I haven't gotten around to testing this, but it looks like adding:

-S /usr/lib/sftp-server

to the "scp" command line would enable the new behavior (i.e., unless/until
I get the newest versions of things installed on my system). Is that
correct? Note that, AFAICT, the option is "-S" (capital S), not "-s".

Note also that, on my system(s), /usr/lib/sftp-server is a symlink to
/usr/lib/openssh/sftp-server.

--
"The most unsettling aspect of my atheism for Christians is
when they realize that their Bible has no power to make me
wince. They are used to using it like a cattle prod to get
people to cower into compliance." - Author unknown

On 2022-12-01, Kenny McCormack <gazelle@shell.xmission.com> wrote:

> I haven't gotten around to testing this, but it looks like adding:
>
> -S /usr/lib/sftp-server
>
> to the "scp" command line would enable the new behavior (i.e., unless/until
> I get the newest versions of things installed on my system). Is that
> correct?

No. In either mode, scp will invoke ssh to connect to the remote
host:

$ scp foo host:bar
will spawn
/usr/bin/ssh -x -oPermitLocalCommand=no -oClearAllForwardings=yes \
-oRemoteCommand=none -oRequestTTY=no -oForwardAgent=no -s -- host sftp

$ scp -O foo host:bar
will spawn
/usr/bin/ssh -x -oPermitLocalCommand=no -oClearAllForwardings=yes \
-oRemoteCommand=none -oRequestTTY=no -oForwardAgent=no -- host scp -t bar

You can use the -S option to replace "/usr/bin/ssh" with something
else. The only practical use that comes to mind would be a wrapper
script that calls /usr/bin/ssh with some additional options, given
that scp doesn't have a configuration file.

- - - -

Nowadays people might no longer know, but Tatu Ylönen wrote ssh as
a drop-in replacement for the Berkeley rlogin/rsh/rcp suite. The
scp command was directly derived from the rcp code; rcp in turn had
been written by Bill Joy all the way back in 1982.

The completely revamped SSH2 protocol gained a whole file transfer
subprotocol (SFTP), for which OpenSSH has provided the sftp(1)
client. However, people prefer the scp(1) command line syntax, so
after years of hemming and hawing, OpenSSH has finally gone ahead
and moved scp over to SFTP, and fixed the quoting issue in the
process--or deliberately broke compatibility, however you want to
see it.

--
Christian "naddy" Weisgerber naddy@mips.inka.de

In article <slrntoi1d6.1ecg.naddy@lorvorc.mips.inka.de>,
Christian Weisgerber <naddy@mips.inka.de> wrote:
>On 2022-12-01, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>
>> I haven't gotten around to testing this, but it looks like adding:
>>
>> -S /usr/lib/sftp-server
>>
>> to the "scp" command line would enable the new behavior (i.e., unless/until
>> I get the newest versions of things installed on my system). Is that
>> correct?
>
>No. In either mode, scp will invoke ssh to connect to the remote
>host:
>
>$ scp foo host:bar
>will spawn
> /usr/bin/ssh -x -oPermitLocalCommand=no -oClearAllForwardings=yes \
> -oRemoteCommand=none -oRequestTTY=no -oForwardAgent=no -s -- host sftp
>
>$ scp -O foo host:bar
>will spawn
> /usr/bin/ssh -x -oPermitLocalCommand=no -oClearAllForwardings=yes \
> -oRemoteCommand=none -oRequestTTY=no -oForwardAgent=no -- host scp -t bar
>
>You can use the -S option to replace "/usr/bin/ssh" with something
>else. The only practical use that comes to mind would be a wrapper
>script that calls /usr/bin/ssh with some additional options, given
>that scp doesn't have a configuration file.
>
>- - - -
>
>Nowadays people might no longer know, but Tatu Ylnen wrote ssh as
>a drop-in replacement for the Berkeley rlogin/rsh/rcp suite. The
>scp command was directly derived from the rcp code; rcp in turn had
>been written by Bill Joy all the way back in 1982.
>
>The completely revamped SSH2 protocol gained a whole file transfer
>subprotocol (SFTP), for which OpenSSH has provided the sftp(1)
>client. However, people prefer the scp(1) command line syntax, so
>after years of hemming and hawing, OpenSSH has finally gone ahead
>and moved scp over to SFTP, and fixed the quoting issue in the
>process--or deliberately broke compatibility, however you want to
>see it.

Again, thanks. Very interesting stuff.

--
1/20/17: A great day for all those people who are sick of being told
they don't know how to spell "you're" (or "there").