GNU bug report logs - #72450
29.1; Tramp Failed to Parse OS Name and Version for Windows 11

Previous Next

Package: emacs;

Reported by: Duncan Greatwood <dgbulk <at> gmail.com>

Date: Sat, 3 Aug 2024 19:55:02 UTC

Severity: normal

Found in version 29.1

Full log


Message #11 received at 72450 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Duncan Greatwood <dgbulk <at> gmail.com>, 72450 <at> debbugs.gnu.org
Subject: Re: bug#72450: 29.1; Tramp Failed to Parse OS Name and Version for
 Windows 11
Date: Sun, 04 Aug 2024 10:28:05 +0200
Eli Zaretskii <eliz <at> 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.




This bug report was last modified 1 year and 5 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.