From: Axel Beckert <email@example.com>
Subject: Re: OpenSSH scp completion reminder
Date: Thu, 14 Apr 2022 19:27:18 +0200 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On Thu, Apr 14, 2022 at 10:04:42AM -0700, Bart Schaefer wrote:
> On Thu, Apr 14, 2022 at 9:43 AM Axel Beckert <email@example.com> wrote:
> > On Thu, Apr 14, 2022 at 11:20:34AM -0400, Phil Pennock wrote:
> > > This change impacts quoting of things like whitespace.
> > > Which I have assumed will impact zsh completion.
> > I thought so as well, but I so far couldn't find anything which didn't
> > work with zsh remote file completion with OpenSSH 9.0 on the client
> > side.
> Completion itself doesn't use scp to do the remote file name
> generation, it uses plain ssh. Of course once the file names are
> returned, getting the quoting right for the actual scp invocation is
> down to what appears on the command line, so the only way completion
> could be implicated in messing this up is if it somehow automatically
> inserted the wrong quoting.
Yep, and that's the point: In theory, the amount of quoting (e.g.
three backslashes vs one backslash) is expected to be different with
the different scp backends. But for some reason the variant with three
backslashes still worked for me with OpenSSH 9.0 on the client side
which defaults to use the SFTP backend which does no shell globbing or
escaping on the server side.
To copy a file named "tmp/foo bar" from remotehost to my local
directory "tmp/", I did:
% scp -p remotehost:tmp/foo<Tab><Tab> tmp/<Enter>
It expanded to:
% scp -p remotehost:tmp/foo\\\ bar tmp/
Accoding to the docs, this does no more work with OpenSSH 9.0's
default settings, but it did. Running "scp" with "-vvvv" confirms that
the new default (SFTP backend) is used:
scp -pvvvv remotehost:tmp/foo\\\ bar tmp/ |& fgrep tmp/foo
scp: debug3: sink_sftp: copying remote tmp/foo\\ bar to local tmp/
scp: debug1: Fetching tmp/foo bar to tmp/foo bar
scp: debug2: do_download: download remote "tmp/foo bar" to local "tmp/foo bar"
scp: debug2: Sending SSH2_FXP_STAT "tmp/foo bar"
scp: debug2: Sending SSH2_FXP_OPEN "tmp/foo bar"
scp: debug3: Sent remote message SSH2_FXP_OPEN I:4 P:tmp/foo bar M:0x0001
It seems as if scp has some capability to recognize of there's too
much shell quoting in a file name and reducres it, since there are
still two backslashes in the first line with "debug3:" which vanish
after that line.
And this even seems to go wrong if I want to copy a file created with
"touch 'foo\ bar'", i.e. with an backslash in there. I would have had
expected that OpenSSH 9.0 would fetch that file with "scp -p
remotehost:tmp/foo\\\ bar tmp/" but it actually stripped the file name
down and I needed five backslashes:
scp -pvvvv remotehost:tmp/foo\\\\\ bar tmp/ |& fgrep tmp/foo
scp: debug3: sink_sftp: copying remote tmp/foo\\\\ bar to local tmp/
scp: debug1: Fetching tmp/foo\\ bar to tmp/foo\\ bar
scp: debug2: do_download: download remote "tmp/foo\\ bar" to local "tmp/foo\\ bar"
scp: debug2: Sending SSH2_FXP_STAT "tmp/foo\\ bar"
scp: debug2: Sending SSH2_FXP_OPEN "tmp/foo\\ bar"
scp: debug3: Sent remote message SSH2_FXP_OPEN I:4 P:tmp/foo\\ bar M:0x0001
Looks like either a bug in OpenSSH 9.0 or an undocumented
compatibility feature to me.
Kind regards, Axel
PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/
Mail: firstname.lastname@example.org \ / Say No to HTML in E-Mail and Usenet
Mail+Jabber: email@example.com X
https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/
next prev parent reply other threads:[~2022-04-14 17:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-14 15:20 Phil Pennock
2022-04-14 16:18 ` Axel Beckert
2022-04-14 17:04 ` Bart Schaefer
2022-04-14 17:27 ` Axel Beckert [this message]
2022-04-14 17:34 ` Mikael Magnusson
2022-04-14 20:44 ` Phil Pennock
2022-04-15 12:46 ` Axel Beckert
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).