From: Mikael Magnusson <email@example.com>
Subject: Re: OpenSSH scp completion reminder
Date: Thu, 14 Apr 2022 19:34:59 +0200 [thread overview]
Message-ID: <CAHYJk3TcZBtfmVy4VqieQALYS203OdPJ9aE5xSzW8r6R1oH92A@mail.gmail.com> (raw)
On 4/14/22, Axel Beckert <firstname.lastname@example.org> wrote:
> 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
> 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
> 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
> Looks like either a bug in OpenSSH 9.0 or an undocumented
> compatibility feature to me.
It's definitely a bug (I'm using 8.9 though):
% touch '\;\['
% scp -s localhost:\\\;\\\[ .
scp: \\;\\[: No such file or directory
% scp -s localhost:\;\[ .
scp: ;[: No such file or directory
It doesn't seem possible to copy files with backslashes in the name at
all using -s.
next prev parent reply other threads:[~2022-04-14 17:35 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
2022-04-14 17:34 ` Mikael Magnusson [this message]
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).