On Wed, Apr 14, 2021 at 4:30 AM Michael Albinus <[email protected]> wrote: > > Jim Porter <[email protected]> writes: > > Hi Jim, > > >> Doesn't work. Do you have an idea, which kind of quoting for the remote > >> target I need? > > > > I haven't spent too much time looking at the scp method under MS > > Windows, but I know there have been some changes to Win32-OpenSSH that > > might affect things here. In v7.9.0.0p1-Beta[1], the quoting logic was > > improved (see the "Rich command-line support..." bullet point in the > > release notes for details). This might fix the issue you're seeing. > > Thanks, this looks helpful!
I tested out Win32-OpenSSH v8.1, and the quoting issue hasn't been resolved. In fact, it's somewhat worse. I found that you can escape the spaces like so: scp "server:~/'foo bar.txt'" dest.txt (1) However, newer versions of OpenSSH have strict filename checking, and the single-quotes run afoul of that check. You can add `-T' to disable that, but older versions of OpenSSH don't support that flag, so you'd have to check the version in use to decide whether to add `-T'. I think it would be a lot better if you could escape the space more like you would on a Linux system, something like: scp "server:~/foo\ bar.txt" dest.txt (2) Then the escaping logic in Tramp could look something like `(client-escape (remote-escape filename))', where `remote-escape' would use backslashes to escape special characters, and `client-escape' would then apply the usual shell-escaping logic for the local system. Since (as I understand it), Tramp requires the server side of the SSH connection to be POSIXy, that would be sufficient if Win32-OpenSSH worked correctly. Hopefully that explains things well enough; these escaping rules are a bit complicated. I filed an issue on the Win32-OpenSSH repo to request that scp accept the example (2) above: https://github.com/PowerShell/Win32-OpenSSH/issues/1790 - Jim
