Shell-quoting issue for sshx/scpx on MS Windows

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Shell-quoting issue for sshx/scpx on MS Windows

Jim Porter
In TRAMP 2.5.0.1, the sshx and scpx methods were changed to use RemoteCommand for specifying, well, the remote command to run (see commit aaffd34492ea6168cc47c469799ac87aa5c052a9[1] for the actual change). However, this was specified as RemoteCommand='%l', which fails on MS Windows systems since they only allow shell-quoting via double quotes.

I've confirmed locally that changing to double quotes, i.e. RemoteCommand="%l", makes everything work correctly. Obviously that isn't what you'd want on a *nix system, but even on MS Windows, I imagine this would fail for multihop cases (e.g. MS Windows -> Linux -> Linux). There might also be further issues with quoting if the %l placeholder is generated with sh-style quotes, but I haven't encountered any problems like that.

- Jim

Reply | Threaded
Open this post in threaded view
|

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

Michael Albinus
Jim Porter <[hidden email]> writes:

Hi Jim,

> In TRAMP 2.5.0.1, the sshx and scpx methods were changed to use
> RemoteCommand for specifying, well, the remote command to run (see
> commit aaffd34492ea6168cc47c469799ac87aa5c052a9[1] for the actual
> change). However, this was specified as RemoteCommand='%l', which
> fails on MS Windows systems since they only allow shell-quoting via
> double quotes.
>
> I've confirmed locally that changing to double quotes, i.e.
> RemoteCommand="%l", makes everything work correctly. Obviously that
> isn't what you'd want on a *nix system, but even on MS Windows, I
> imagine this would fail for multihop cases (e.g. MS Windows -> Linux -
>> Linux). There might also be further issues with quoting if the %l
> placeholder is generated with sh-style quotes, but I haven't
> encountered any problems like that.

A few days ago I've changed sshx/scpx methods on MS Windows to use
powershell as local encoding shell. With this, the template
RemoteCommand='%l' seems to work well.

Would you mind to test it in your environment? Honestly, I'm kind of
restricted, because I don't run MS Windows on my machines.

You can either use Tramp sources from git. Or, if this is inconvenient,
I could provide you a pre-release of the upcoming Tramp 2.5.0.4.

> - Jim

Best regards, Michael.

Reply | Threaded
Open this post in threaded view
|

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

Jim Porter
On Wed, Apr 7, 2021 at 12:56 AM Michael Albinus <[hidden email]> wrote:
A few days ago I've changed sshx/scpx methods on MS Windows to use
powershell as local encoding shell. With this, the template
RemoteCommand='%l' seems to work well.

Would you mind to test it in your environment? Honestly, I'm kind of
restricted, because I don't run MS Windows on my machines.

It works! One thing I noticed while testing, however, is that there are a couple of cases where the latest git revision is quite a bit slower than Tramp 2.5.0.3. This might be due to the switch to Powershell, or perhaps something else has changed.

The biggest performance issue that I saw is exiting from M-x gdb[1]. Using sshx on Tramp 2.5.0.3 (with the quoting fix for RemoteCommand), after M-x gdb, I can hit C-d in the gud buffer to stop debugging, and it's almost instant. On the latest git revision, Emacs hangs for a couple seconds after hitting C-d.

Another particularly-noticeable case is disabling auto-revert-mode in a remote buffer (again using sshx). That too was almost instant on 2.5.0.3, but takes a couple seconds on the latest git. Enabling auto-revert-mode is fast on both versions, although I think 2.5.0.3 is still faster. Other things might also be slower on the latest git, but nothing else stuck out during my tests.

All the above cases were tested with a Windows 10 system using the default MS-provided OpenSSH client and connecting via sshx to a Linux VM running on localhost. I tried with scpx too, and things seem to be the same there. I'll send some Tramp debug logs off-list for the M-x gdb test in case they're useful for you (I don't think there's any sensitive information in them, but better safe than sorry).

Thanks,
- Jim

[1] Caveat: there are a couple issues in core Emacs preventing M-x gdb from fully working over Tramp, but they shouldn't affect this test. I'll be submitting patches for these problems once I get them extracted from my .emacs and cleaned up a bit.
Reply | Threaded
Open this post in threaded view
|

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

Michael Albinus
Jim Porter <[hidden email]> writes:

Hi Jim,

>     A few days ago I've changed sshx/scpx methods on MS Windows to use
>     powershell as local encoding shell. With this, the template
>     RemoteCommand='%l' seems to work well.
>
>     Would you mind to test it in your environment? Honestly, I'm kind
>     of
>     restricted, because I don't run MS Windows on my machines.
>
> It works! One thing I noticed while testing, however, is that there
> are a couple of cases where the latest git revision is quite a bit
> slower than Tramp 2.5.0.3. This might be due to the switch to
> Powershell, or perhaps something else has changed.

Yes, it is related. Powershell does not understand the "&& exit || exit"
pattern, so I've changed it to "; exit". Likely, this is slower.

So I've reverted the use of powershell in Tramp on MS Windows. Instead,
I'm using the "double apostroph" quoting as suggested by you, and this
works proper.

Side remark: Since I don't use MS Windows myself, I heavily depend on
reports of people using Emacs/Tramp there. Thanks a lot for your report
and your suggestions, again!

> The biggest performance issue that I saw is exiting from M-x gdb[1].
> Using sshx on Tramp 2.5.0.3 (with the quoting fix for RemoteCommand),
> after M-x gdb, I can hit C-d in the gud buffer to stop debugging, and
> it's almost instant. On the latest git revision, Emacs hangs for a
> couple seconds after hitting C-d.
>
> Another particularly-noticeable case is disabling auto-revert-mode in
> a remote buffer (again using sshx). That too was almost instant on
> 2.5.0.3, but takes a couple seconds on the latest git. Enabling
> auto-revert-mode is fast on both versions, although I think 2.5.0.3 is
> still faster. Other things might also be slower on the latest git, but
> nothing else stuck out during my tests.
>
> All the above cases were tested with a Windows 10 system using the
> default MS-provided OpenSSH client and connecting via sshx to a Linux
> VM running on localhost. I tried with scpx too, and things seem to be
> the same there. I'll send some Tramp debug logs off-list for the M-x
> gdb test in case they're useful for you (I don't think there's any
> sensitive information in them, but better safe than sorry).

Could you pls pull the recent git sources, and check whether it makes a
difference?

> Thanks,
> - Jim
>
> [1] Caveat: there are a couple issues in core Emacs preventing M-x gdb
> from fully working over Tramp, but they shouldn't affect this test.
> I'll be submitting patches for these problems once I get them
> extracted from my .emacs and cleaned up a bit.

Please do, this will be much appreciated!

Best regards, Michael.

Reply | Threaded
Open this post in threaded view
|

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

Jim Porter
On Thu, Apr 8, 2021 at 3:32 AM Michael Albinus <[hidden email]> wrote:
> Yes, it is related. Powershell does not understand the "&& exit || exit"
> pattern, so I've changed it to "; exit". Likely, this is slower.
>
> So I've reverted the use of powershell in Tramp on MS Windows. Instead,
> I'm using the "double apostroph" quoting as suggested by you, and this
> works proper.

Good to hear this works for you as well. I tested locally with the
latest git revision on both MS Windows and Linux (including multi-hop
from MS Windows -> Linux -> Linux), and everything works as I'd
expect.

> Side remark: Since I don't use MS Windows myself, I heavily depend on
> reports of people using Emacs/Tramp there. Thanks a lot for your report
> and your suggestions, again!

I'm glad to be of help. Thanks for all your efforts in maintaining and
improving Tramp! It's consistently improved since I started using it
several years ago, and now works/performs just about as well on MS
Windows as it does on Linux.

> Could you pls pull the recent git sources, and check whether it makes a
> difference?

Everything seems good to me. I couldn't find any problems, and there's
no longer a hang when exiting GDB.

Thanks,
- Jim

Reply | Threaded
Open this post in threaded view
|

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

Michael Albinus
Jim Porter <[hidden email]> writes:

Hi Jim,

>> So I've reverted the use of powershell in Tramp on MS Windows. Instead,
>> I'm using the "double apostroph" quoting as suggested by you, and this
>> works proper.
>
> Good to hear this works for you as well. I tested locally with the
> latest git revision on both MS Windows and Linux (including multi-hop
> from MS Windows -> Linux -> Linux), and everything works as I'd
> expect.

Thanks for testing. With "working proper" I meant the Linux and FrreBSD
cases I'm able to test. Good to get feedback for MS Windows.

>> Could you pls pull the recent git sources, and check whether it makes a
>> difference?
>
> Everything seems good to me. I couldn't find any problems, and there's
> no longer a hang when exiting GDB.

What I'm thinking for a longer time is to enable remote processes on MS
Windows, as remote target. AFAIK there is also an OpenSSH server for
that beast, so it must be possible to start remote processes via ssh
from a local Emacs running on, let's say, Linux.

The smb method must be extended for this, but that shall be
possible. ATM, smb-like connections use winexe for remote processes on
MS Windows. But I don't know whether this is really used by somebody,
and winexe doesn't seem to be maintained anymore. I even don't know
whether it is cooperating with MS Windows 10. WDYT?

> Thanks,
> - Jim

Best regards, Michael.

Reply | Threaded
Open this post in threaded view
|

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

Jim Porter
On Fri, Apr 9, 2021 at 12:28 AM Michael Albinus <[hidden email]> wrote:
> What I'm thinking for a longer time is to enable remote processes on MS
> Windows, as remote target. AFAIK there is also an OpenSSH server for
> that beast, so it must be possible to start remote processes via ssh
> from a local Emacs running on, let's say, Linux.

There is, and I've tinkered with connecting via Tramp to an MS Windows
server running OpenSSH. However, when using ssh from a local MS
Windows client, I need to use the sshx method or Tramp hangs (this is
mentioned in the Tramp manual: "sshx is useful for MS Windows users
when ssh triggers an error about allocating a pseudo tty."). This
works fine when the server is Linux, but on MS Windows, running "ssh
-t" results in the Windows OpenSSH server replying with a bunch of
ANSI escapes that (I think) confuses Tramp.

There's a Github issue about this[1] that includes the following
helpful description:

"Due to a historical mistake, we gave Win32 applications full
read/write access to any rectangular region in the entire scrollback
buffer--including the viewport. To offer maximum compatibility for
those applications² the hosting APIs clear the screen by default,
unless the application requests cursor position inheritance¹.

"¹ This works by sending DSR-CPR and awaiting CPR. It won't work
without a compliant terminal emulator."

Perhaps Tramp can reply with the appropriate ANSI escape in this case
to make things work. Or perhaps not. I haven't had a chance to dig
into this very deeply, but when I get the time, I'll try to collect
some logs and narrow down the problem so I can send the results to the
list.

> The smb method must be extended for this, but that shall be
> possible. ATM, smb-like connections use winexe for remote processes on
> MS Windows. But I don't know whether this is really used by somebody,
> and winexe doesn't seem to be maintained anymore. I even don't know
> whether it is cooperating with MS Windows 10. WDYT?

I haven't spent much time looking at the smb method, since it would
require a bit more setup when using from an MS Windows client (I don't
have smbclient installed). While I use Tramp on both MS Windows and
Linux, I've only ever had a need to connect *to* an MS Windows server
when I'm running MS Windows locally too.

The smb method is surely useful for connecting to MS Windows servers
that don't have OpenSSH server installed. However, the OpenSSH
client/server are easy to install on MS Windows now, so it might make
sense to focus improvements for Tramp+Windows on the sshx/scpx
methods. These methods have been very reliable for me when connecting
from MS Windows, so hopefully it won't be too complicated to work
around the strangeness described above when connecting to an MS
Windows server.

- Jim

[1] https://github.com/PowerShell/Win32-OpenSSH/issues/1738

Reply | Threaded
Open this post in threaded view
|

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

Michael Albinus
Jim Porter <[hidden email]> writes:

Hi Jim,

>> What I'm thinking for a longer time is to enable remote processes on MS
>> Windows, as remote target. AFAIK there is also an OpenSSH server for
>> that beast, so it must be possible to start remote processes via ssh
>> from a local Emacs running on, let's say, Linux.
>
> There is, and I've tinkered with connecting via Tramp to an MS Windows
> server running OpenSSH. However, when using ssh from a local MS
> Windows client, I need to use the sshx method or Tramp hangs (this is
> mentioned in the Tramp manual: "sshx is useful for MS Windows users
> when ssh triggers an error about allocating a pseudo tty."). This
> works fine when the server is Linux, but on MS Windows, running "ssh
> -t" results in the Windows OpenSSH server replying with a bunch of
> ANSI escapes that (I think) confuses Tramp.
>
> There's a Github issue about this[1] that includes the following
> helpful description:
>
> "Due to a historical mistake, we gave Win32 applications full
> read/write access to any rectangular region in the entire scrollback
> buffer--including the viewport. To offer maximum compatibility for
> those applications² the hosting APIs clear the screen by default,
> unless the application requests cursor position inheritance¹.
>
> "¹ This works by sending DSR-CPR and awaiting CPR. It won't work
> without a compliant terminal emulator."
>
> Perhaps Tramp can reply with the appropriate ANSI escape in this case
> to make things work. Or perhaps not. I haven't had a chance to dig
> into this very deeply, but when I get the time, I'll try to collect
> some logs and narrow down the problem so I can send the results to the
> list.

Accessing an ssh server on MS Windows via Tramp will fail in general,
because Tramp expects a POSIX shell on the server side. If I read the
docs correctly, the ssh server on MS Windows opens a powershell.

The problem with the escape sequences reminds me to similar problems
when using mosh as local ssh client vin Tramp. That's also still
unresolved, it would require a general attempt to solve such problems in
Tramp.

>> The smb method must be extended for this, but that shall be
>> possible. ATM, smb-like connections use winexe for remote processes on
>> MS Windows. But I don't know whether this is really used by somebody,
>> and winexe doesn't seem to be maintained anymore. I even don't know
>> whether it is cooperating with MS Windows 10. WDYT?
>
> I haven't spent much time looking at the smb method, since it would
> require a bit more setup when using from an MS Windows client (I don't
> have smbclient installed). While I use Tramp on both MS Windows and
> Linux, I've only ever had a need to connect *to* an MS Windows server
> when I'm running MS Windows locally too.

Well, the smbclient is intended to be used from Linux (or *BSD) only.
When you run Emacs on MS Windows, you can use UNC file names.

> The smb method is surely useful for connecting to MS Windows servers
> that don't have OpenSSH server installed. However, the OpenSSH
> client/server are easy to install on MS Windows now, so it might make
> sense to focus improvements for Tramp+Windows on the sshx/scpx
> methods. These methods have been very reliable for me when connecting
> from MS Windows, so hopefully it won't be too complicated to work
> around the strangeness described above when connecting to an MS
> Windows server.

Again, there is the missing POSIX shell issue. That's why I was thinking
only about running remote processes this way.

An alternative approach could be to run powershell on Linux, and to run
a remote process on MS Windows via powershell "Invoke-Command".

> - Jim

Best regards, Michael.

Reply | Threaded
Open this post in threaded view
|

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

Jim Porter
On Sat, Apr 10, 2021 at 6:20 AM Michael Albinus <[hidden email]> wrote:
>
> Jim Porter <[hidden email]> writes:
[snip]
> > Perhaps Tramp can reply with the appropriate ANSI escape in this case
> > to make things work. Or perhaps not. I haven't had a chance to dig
> > into this very deeply, but when I get the time, I'll try to collect
> > some logs and narrow down the problem so I can send the results to the
> > list.
>
> Accessing an ssh server on MS Windows via Tramp will fail in general,
> because Tramp expects a POSIX shell on the server side. If I read the
> docs correctly, the ssh server on MS Windows opens a powershell.

You can actually set the default ssh shell on MS Windows to be a POSIX
shell by setting a registry value[1]. I've tried this and it works
well when using PuTTY or ssh via the command line, though the ANSI
escapes are still there, and I haven't been able to get it to work
through Tramp yet.

The ubiquity of Git has a nice side effect here: every MS Windows
system with Git installed has sh.exe and dozens of other common POSIX
programs in .../Git/usr/bin. In theory, Tramp (or the user) just needs
to change the `tramp-remote-shell' property from "/bin/sh" to
"C:/Program Files/Git/usr/bin/sh.exe"[2] when connecting to an MS
Windows server. If the ANSI escape issue is resolved, setting
`tramp-remote-shell' might be enough to allow connecting to MS Windows
servers via sshx. I'm still not 100% sure the ANSI escapes are the
problem, but if so, this would hopefully reduce the amount of effort
required to make this work.

- Jim

[1] https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_server_configuration#configuring-the-default-shell-for-openssh-in-windows
[2] Or wherever Git is installed on the server

Reply | Threaded
Open this post in threaded view
|

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

Michael Albinus
Jim Porter <[hidden email]> writes:

Hi Jim,

>> Accessing an ssh server on MS Windows via Tramp will fail in general,
>> because Tramp expects a POSIX shell on the server side. If I read the
>> docs correctly, the ssh server on MS Windows opens a powershell.
>
> You can actually set the default ssh shell on MS Windows to be a POSIX
> shell by setting a registry value[1]. I've tried this and it works
> well when using PuTTY or ssh via the command line, though the ANSI
> escapes are still there, and I haven't been able to get it to work
> through Tramp yet.
>
> The ubiquity of Git has a nice side effect here: every MS Windows
> system with Git installed has sh.exe and dozens of other common POSIX
> programs in .../Git/usr/bin. In theory, Tramp (or the user) just needs
> to change the `tramp-remote-shell' property from "/bin/sh" to
> "C:/Program Files/Git/usr/bin/sh.exe"[2] when connecting to an MS
> Windows server. If the ANSI escape issue is resolved, setting
> `tramp-remote-shell' might be enough to allow connecting to MS Windows
> servers via sshx. I'm still not 100% sure the ANSI escapes are the
> problem, but if so, this would hopefully reduce the amount of effort
> required to make this work.

That's possible, yes. But besides the POSIX shell, Tramp needs on the
remote side also some POSIX tools, like find, grep, stat, you name it.

Might be worth to try it, but since I don't run a (remote) MS Windows
machine, I have no chance to test.

> - Jim

Best regards, Michael.

Reply | Threaded
Open this post in threaded view
|

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

Jim Porter
On Sun, Apr 11, 2021 at 3:51 AM Michael Albinus <[hidden email]> wrote:

> Jim Porter <[hidden email]> writes:
> > The ubiquity of Git has a nice side effect here: every MS Windows
> > system with Git installed has sh.exe and dozens of other common POSIX
> > programs in .../Git/usr/bin. In theory, Tramp (or the user) just needs
> > to change the `tramp-remote-shell' property from "/bin/sh" to
> > "C:/Program Files/Git/usr/bin/sh.exe"[2] when connecting to an MS
> > Windows server. If the ANSI escape issue is resolved, setting
> > `tramp-remote-shell' might be enough to allow connecting to MS Windows
> > servers via sshx. I'm still not 100% sure the ANSI escapes are the
> > problem, but if so, this would hopefully reduce the amount of effort
> > required to make this work.
>
> That's possible, yes. But besides the POSIX shell, Tramp needs on the
> remote side also some POSIX tools, like find, grep, stat, you name it.
>
> Might be worth to try it, but since I don't run a (remote) MS Windows
> machine, I have no chance to test.
Git hopefully provides enough on MS Windows. I've attached a list of
all the executable files in "C:/Program Files/Git/usr/bin" in case you
want to see what's available. I think the first thing would be for me
to try adding support for the necessary ANSI escape response to
satisfy MS Windows' OpenSSH server; I'll see if I can figure out how
to do that when I get the chance. I'll let you know how that goes.

- Jim

git-usr-bin.txt (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Michael Albinus
Jim Porter <[hidden email]> writes:

Hi Jim,

>> That's possible, yes. But besides the POSIX shell, Tramp needs on the
>> remote side also some POSIX tools, like find, grep, stat, you name it.
>>
>> Might be worth to try it, but since I don't run a (remote) MS Windows
>> machine, I have no chance to test.
>
> Git hopefully provides enough on MS Windows. I've attached a list of
> all the executable files in "C:/Program Files/Git/usr/bin" in case you
> want to see what's available. I think the first thing would be for me
> to try adding support for the necessary ANSI escape response to
> satisfy MS Windows' OpenSSH server; I'll see if I can figure out how
> to do that when I get the chance. I'll let you know how that goes.

Thanks for the list, it looks good. Alternatively, there is the mingw
project, which offers also POSIX programs. I haven't tried either.

In order to make progress, I have installed MS Windows 10 in a virtual
machine, and I have bought an MS Windows license. This allows me to test
ssh and scp on MS Windows myself. Sadly, the sshd daemon does not start,
I need to figure out what's up.

Anyway, the Tramp test suite does not run through. Copying files with a
space in their file name, via scp, does not work. I guess it needs kind
of quoting, but I don't know which. See

--8<---------------cut here---------------start------------->8---
scp albinus@gandalf:/home/albinus/.emacs "c:/Users/albinus/AppData/Local/Temp/foo bar baz"
--8<---------------cut here---------------end--------------->8---

Quoting a local file name works.

--8<---------------cut here---------------start------------->8---
scp "c:/Users/albinus/AppData/Local/Temp/foo bar baz" albinus@gandalf:/home/albinus/tmp
--8<---------------cut here---------------end--------------->8---

This works also. "/home/albinus/tmp/foo bar baz" has appeared on the
remote machine.

--8<---------------cut here---------------start------------->8---
scp "c:/Users/albinus/AppData/Local/Temp/foo bar baz" "albinus@gandalf:/home/albinus/tmp/blub bla"
scp: ambiguous target
--8<---------------cut here---------------end--------------->8---

Doesn't work. Do you have an idea, which kind of quoting for the remote
target I need?

> - Jim

Best regards, Michael.

Reply | Threaded
Open this post in threaded view
|

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

Jim Porter
On Tue, Apr 13, 2021 at 10:52 AM Michael Albinus <[hidden email]> wrote:

> Anyway, the Tramp test suite does not run through. Copying files with a
> space in their file name, via scp, does not work. I guess it needs kind
> of quoting, but I don't know which. See
>
> --8<---------------cut here---------------start------------->8---
> scp albinus@gandalf:/home/albinus/.emacs "c:/Users/albinus/AppData/Local/Temp/foo bar baz"
> --8<---------------cut here---------------end--------------->8---
>
> Quoting a local file name works.
>
> --8<---------------cut here---------------start------------->8---
> scp "c:/Users/albinus/AppData/Local/Temp/foo bar baz" albinus@gandalf:/home/albinus/tmp
> --8<---------------cut here---------------end--------------->8---
>
> This works also. "/home/albinus/tmp/foo bar baz" has appeared on the
> remote machine.
>
> --8<---------------cut here---------------start------------->8---
> scp "c:/Users/albinus/AppData/Local/Temp/foo bar baz" "albinus@gandalf:/home/albinus/tmp/blub bla"
> scp: ambiguous target
> --8<---------------cut here---------------end--------------->8---
>
> 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.
This will probably mean manually installing[2] Win32-OpenSSH, since
Microsoft is very conservative about publishing OpenSSH updates via
their Windows Update service. I haven't tried this yet though, so I
can't be sure if it fixes the issue you're seeing.

v7.9 also includes support for ConPTY (the "Windows Pseudo
Console")[3]. This seems to be relevant mostly for the OpenSSH server,
and might make things work better when connecting to an MS Windows
system; that probably first requires Tramp to handle the ANSI escapes
I mentioned previously, though.

- Jim

[1] https://github.com/PowerShell/Win32-OpenSSH/releases/tag/v7.9.0.0p1-Beta
[2] https://github.com/PowerShell/Win32-OpenSSH/wiki/Install-Win32-OpenSSH
[3] https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/

Reply | Threaded
Open this post in threaded view
|

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

Michael Albinus
Jim Porter <[hidden email]> 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!

> This will probably mean manually installing[2] Win32-OpenSSH, since
> Microsoft is very conservative about publishing OpenSSH updates via
> their Windows Update service. I haven't tried this yet though, so I
> can't be sure if it fixes the issue you're seeing.

--8<---------------cut here---------------start------------->8---
ssh -V
OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5
--8<---------------cut here---------------end--------------->8---

Well, I don't know whether I bite the bullet to support beta versions on
MS Windows. I guess I'll just add a comment in
tramp-make-copy-program-file-name, and I'll wait until OpenSSH 7.9 is
released officially for MS Windows.

> v7.9 also includes support for ConPTY (the "Windows Pseudo
> Console")[3]. This seems to be relevant mostly for the OpenSSH server,
> and might make things work better when connecting to an MS Windows
> system; that probably first requires Tramp to handle the ANSI escapes
> I mentioned previously, though.

Looks also interesting. For the ANSI escape sequences, you might look at
tramp-display-escape-sequence-regexp and tramp-device-escape-sequence-regexp
and how they are used in tramp-sh.el. They are intended for handling
escape sequences emitted by the server; maybe you could do something
similar. As said, until I get sshd running on my MS Windows machine, I
cannot test myself.

> - Jim

Best regards, Michael.