GNU bug report logs -
#72450
29.1; Tramp Failed to Parse OS Name and Version for Windows 11
Previous Next
Full log
Message #65 received at 72450 <at> debbugs.gnu.org (full text, mbox):
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 <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.
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.
This bug report was last modified 1 year and 4 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.