Jim Porter <[email protected]> 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.
