Re: Shell-quoting issue for sshx/scpx on MS Windows

[Jim Porter]

On Sun, May 9, 2021 at 6:40 AM Michael Albinus <michael.albinus@gmx.de> wrote:
> Finally, I've found out that pscp has *exactly* the same problem as
> scp. It doesn't support a double-quote in the file name, for example:
>
> --8<---------------cut here---------------start------------->8---
> C:\Users\albinus>scp -T -q -r gandalf:/home/albinus/x""z .
> scp: /home/albinus/xz: No such file or directory
>
> C:\Users\albinus>pscp -scp -p -q -r gandalf:/home/albinus/x""z .
> scp: /home/albinus/xz: No such file or directory
> --8<---------------cut here---------------end--------------->8---

There's something unusual happening with how shell escaping works on
MS Windows... pscp works fine for me on Tramp 2.5.0.4, but fails on
quoted files in the development build. See the table at the end for
the results; for consistency with my last set of tests, "tramp-dev2"
is commit 13b41389. However, I also tried with the latest Tramp commit
(0b8bb839), and it seems to fail in the same ways.

Surprisingly, if I take the very same command from the "Tramp 2.5.0.4
+ pscp" logs and run it in a Windows Console, it fails:

  pscp -scp -p -q -r server:/home/jim/a\ \"quoted\"\ file.txt .
  More than one remote source not supported

I wasn't able to figure out how to add quotes in a way that made the
console happy, so I tried doing it in Python, where I can specify each
command line argument as a different string, and avoid the Windows
Console logic:

  import subprocess
  subprocess.run([
      'pscp', '-scp', '-p', '-q', '-r',
      'server:/home/jim/a\\ \\"quoted\\"\\ file.txt', 'dest.txt'
  ])

That works correctly. It also works correctly if I use the MSYS2
OpenSSH port. However, doing the same for the Win32 OpenSSH port fails
with the following output:

  scp: /home/jim/a: No such file or directory
  scp: /quoted: No such file or directory
  scp: file.txt: No such file or directory

I think that when Tramp invokes scp (or pscp), it's not actually
sending the command string to the Windows Console, and is just running
it directly. The source for `nt/cmdproxy.c' mentions this:

     If not running interactively, then attempt to execute the specified
     command directly.  If necessary, spawn a real shell to execute the
     command.

Since the command string doesn't have any special shell characters,
cmdproxy should just run it directly, avoiding the Windows Console
escaping logic. At least, I think that's what's happening...

In any case, based on my tests, Tramp 2.5.0.4's behavior is correct
for PuTTY as well as the MSYS2 port of OpenSSH, but breaks when using
special characters with the Win32 port of OpenSSH. The development
version of Tramp fails with PuTTY and the MSYS2 port of OpenSSH, but
works for *most* special characters with the Win32 port of OpenSSH.
Having an option like you mentioned to opt into the DOS/Windows-style
shell-escaping would probably fix PuTTY and MSYS2 OpenSSH, while still
allowing Win32 OpenSSH users to have something that mostly works.

(I still haven't gotten the time to read over the docs on running
Tramp's automated tests. Hopefully I can get to that soon, since it
would be a lot more thorough than my manual tests.)

- Jim

---------- Begin Table ----------

tramp-2.5.0.4  putty-0.70  spaces    ok
  pscp -scp -p -q -r server:/home/jim/foo\ bar.txt [[dest]]

tramp-2.5.0.4  putty-0.70  quotes    ok
  pscp -scp -p -q -r server:/home/jim/a\ \"quoted\"\ file.txt [[dest]]


tramp-dev2  putty-0.70  spaces    ok
  pscp -scp -p -q -r server:"/home/jim/foo bar.txt" [[dest]]

tramp-dev2  putty-0.70  quotes    FAIL
  pscp -scp -p -q -r server:"/home/jim/a ""quoted"" file.txt" [[dest]]
  scp: /home/jim/a quoted file.txt: No such file or directory

---------- End Table ----------