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

[Michael Albinus via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Duncan and Eli,

>> I am seeing the following error from Tramp:
>> tramp-error: ‘echo \"`uname -sr`\"’ does not return a valid Lisp expression: ‘"MSYS_NT-10.0-22631
>> 3.4.10-87d57229.x86_64" [17;120H’

Well, the problem is the trailing '[17;120H' in the output, which looks
like an ESCAPE sequence. I have nod idea what it is good for. Tramp
doesn't expect it, and raises an error during a sanity check. The string
returned by 'uname -sr' looks proper.

>> By default, the shell produced for the ssh to windows is a PowerShell, which I can well understand is not what
>> Tramp expects; Tramp was producing an error "Couldn't find remote shell prompt for /bin/sh". 

Correct.

>> To address, now I detect the tramp attach on the Windows side and, in the Tramp case, move to shell "sh" for
>> the Windows prompt.

OK.

> My suggestion is not to have the MSYS 'uname' on your Path.  I think
> it gets in the way, and Tramp doesn't really need it on Windows.

I don't know, whether it is the MSYS 'uname', or something else on the
remote side, which produces the ESCAPE sequence.

> Michael, am I right?

Tramp calls 'uname -sr' for a reason. It checks, whether the remote
system has changed its kernel since the last visit, and in case of, it
invalidates all cached values.

> In general, too many Windows users of Emacs install MSYS in a way that
> its utilities are on the system-wide Path, without understanding the
> caveats and subtle issues this could cause.

First we need to know where the ESCAPE sequence comes from. Any idea?

Best regards, Michael.