zsh-workers
 help / color / mirror / code / Atom feed
From: Mikael Magnusson <mikachu@gmail.com>
To: zsh-workers@zsh.org
Subject: Re: OpenSSH scp completion reminder
Date: Thu, 14 Apr 2022 19:34:59 +0200	[thread overview]
Message-ID: <CAHYJk3TcZBtfmVy4VqieQALYS203OdPJ9aE5xSzW8r6R1oH92A@mail.gmail.com> (raw)
In-Reply-To: <20220414172717.nfjrqfa7ebm5xloo@sym.noone.org>

On 4/14/22, Axel Beckert <abe@deuxchevaux.org> wrote:
> Hi,
>
> On Thu, Apr 14, 2022 at 10:04:42AM -0700, Bart Schaefer wrote:
>> On Thu, Apr 14, 2022 at 9:43 AM Axel Beckert <abe@deuxchevaux.org> 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.

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.

-- 
Mikael Magnusson


  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

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAHYJk3TcZBtfmVy4VqieQALYS203OdPJ9aE5xSzW8r6R1oH92A@mail.gmail.com \
    --to=mikachu@gmail.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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

	https://git.vuxu.org/mirror/zsh/

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).