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

Previous Next

Full log

View this message in rfc822 format

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Duncan Greatwood <dgreatwood <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, dgbulk <at> gmail.com, 72450 <at> debbugs.gnu.org
Subject: bug#72450: 29.1; Tramp Failed to Parse OS Name and Version for Windows 11
Date: Mon, 05 Aug 2024 10:27:49 +0200

Duncan Greatwood <dgreatwood <at> 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.

> i) the target windows machine is not directly accessible right now, it
> is accessible via an intervening ssh proxy;

That's a valid point. So we need to find a solution.

> ii) SMB seems pretty retro to me in 2024, but maybe that's just me.

Yes, it is just you.

> 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. 

> BTW, emacs seems to be taking some time before finally producing an
> error message. If there is a way to log what is happening in emacs -
> what tramp is trying, what happens, etc., I'd be happy to. Or LMK how
> I could help otherwise.

Set tramp-verbose to 6 in a new Emacs session, prior the ssh
connection. When it has failed, there is a *debug tramp/ssh ...*
buffer; please send it as attachment.

> Best
> -DG

Best regards, Michael.

Previous Next

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