bug#72450: 29.1; Tramp Failed to Parse OS Name and Version for Windows 11

[Jim Porter <jporterbugs@gmail.com>]

On 8/5/2024 1:27 AM, Michael Albinus via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> Duncan Greatwood <dgreatwood@gmail.com> writes:
> 
>> Hi Michael and Eli -
> 
> Hi Duncan,
> 
>>      sh-5.2$ uname --version
>>      uname (GNU coreutils) 8.32
>>      Copyright (C) 2020 Free Software Foundation, Inc.
>>      License GPLv3+: GNU GPL version 3 or later
>>      <https://gnu.org/licenses/gpl.html>.
>>      This is free software: you are free to change and redistribute it.
>>      There is NO WARRANTY, to the extent permitted by law.
>>
>>      Written by David MacKenzie.
>>      sh-5.2$
>>
>> If I may, the extra characters in the emacs error message might not
>> come from the uname on windows - that uname seems to work OK on the
>> windows side at least - it could be a misparsing in emacs (or even an
>> mistake gathering the error message, I suppose).
> 
> I also don't believe it comes from uname itself. '[17;120H’' looks
> rather like an escape code sequence, perhaps emitted from the underlying
> shell. Something like cursor position, window setting, whatever. A
> search didn't gave me a clue what's this.
> 
> After connecting the remote host via ssh, Tramp sends as very first
> command something like
> 
> --8<---------------cut here---------------start------------->8---
> # exec env TERM='dumb' INSIDE_EMACS='31.0.50,tramp:2.8.0-pre' ENV='' HISTFILE=~/.tramp_history PROMPT_COMMAND='' PS1=///245adade605348c086dac6d8f612435c\#\$ PS2='' PS3='' /bin/sh  -i
> --8<---------------cut here---------------end--------------->8---
> 
> Note the TERM='dumb' setting, which ought to suppress such code
> sequences.
> 
> Somehow, this doesn't seem to work as expected in your case. Perhaps due
> to calling /bin/sh. See below for debugging instructions.

Regarding the unusual cursor-positioning ANSI sequences, I may know what 
this is, since I encountered something similar before: 
<https://lists.gnu.org/archive/html/tramp-devel/2021-04/msg00024.html>.

This is apparently just another one of those sharp corners on MS-Windows 
that we have to deal with for the sake of backwards compatibility 
(nice), but that there's no clear way to opt out of (not so nice): 
<https://github.com/PowerShell/Win32-OpenSSH/issues/1738>.

>>  From an emacs perspective, it seems a shame not to be able to use ssh,
>> given that modern Windows commonly supports ssh and provides a bash
>> shell. Depending on your own available bandwidth etc. of course.
> 
> That is NOT a shame. MS Windows is a non-free operation system,
> therefore it isn't a primary target for Emacs development.
> 
> And it doesn't seem to be important. I'm working for Tramp for more than
> 20 years. During this time, nobody has contributed anything for the sake
> of MS Windows. And I don't use MS Windows myself; if possible, I fix
> things, that's it.

Well, I've tried to help make Tramp work a bit better on MS-Windows (my 
first Emacs patch was to fix Tramp hostname completion on MS-Windows 
;)), but this bug is the one where I finally gave up: there's a point 
where trying to fix Microsoft's mistakes just becomes too time-consuming 
and bothersome, so I focused my energies elsewhere.

As it's been a few years since I looked at this last, the residual 
irritation has certainly subsided so I wouldn't mind trying to help out 
in some way, but I'm not sure I have the patience to come up with a 
patch for this myself.