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

[Michael Albinus]

Jim Porter <jporterbugs@gmail.com> 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.