Bug#923286: scp: 'protocol error: filename does not match request' even though it does match

[Colin Watson <cjwatson@debian.org>]

On Mon, Feb 25, 2019 at 10:22:55PM +0100, Ansgar Burchardt wrote:
> The file "This is a [file].txt" (w/o quotes) exists on `remote`.
> 
> The following does no longer work:
> 
>    $ scp remote:'./"This is a [file].txt"' blubb
>    protocol error: filename does not match request

Hi,

Would you mind filing this directly upstream (bugzilla.mindrot.org)?
They seem to have been doing a fair bit of work on this lately, and will
probably appreciate a direct heads-up of regressions.

> These however do still work:
> 
>    $ scp remote:'"This is a [file].txt"' blubb
>    $ scp remote:'./This\ is\ a\ \[file\].txt' blubb
>    $ scp remote:'This\ is\ a\ \[file\].txt' blubb

Even these don't work as of upstream commit
3d896c157c722bc47adca51a58dca859225b5874.

> Extended globs (from zsh) now only work sometimes as well:
> 
>    $ scp daikoku:'./This\ is\ a\ \[file\].txt(.)' blubb
>    protocol error: filename does not match request
>    $ scp daikoku:'This\ is\ a\ \[file\].txt(.)' blubb

I'm not sure if these will ever work, seeing as upstream seems to be
moving in the direction of implementing the wildcard expansions
themselves.

That said, using the new -T option makes the scp client trust the
server's wildcard expansion.  I haven't tested the zsh extended glob
case, but it makes all your other examples work.

Thanks,

-- 
Colin Watson                                       [cjwatson@debian.org]