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

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

[Duncan Greatwood]

[-- Attachment #1: Type: text/plain, Size: 7925 bytes --]

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’

Background:

I have a "Windows 11 Home Edition" remote machine, and am seeking to
connect to that machine from emacs run on macOS.

In emacs, I am doing:
(find-file "/ssh:WINUSERNAME@WIN11HOME:WINPATH")
with suitable values for WINUSERNAME, WIN11HOME, WINPATH.

I can ssh to WIN11HOME (it is running the OpenSSH Server), using keys
stored locally in my macOS.

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

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.

Thereafter, tramp produces the "uname/lisp" error above.

FYI, from the windows side:
    sh-5.2$ uname -sr
    MSYS_NT-10.0-22631 3.4.10-87d57229.x86_64

Thanks in advance.
------

In GNU Emacs 29.1 (build 1, aarch64-apple-darwin21.6.0, NS
 appkit-2113.60 Version 12.6.6 (Build 21G646)) of 2023-08-16 built on
 armbob.lan
Windowing system distributor 'Apple', version 10.3.2487
System Description:  macOS 14.5

Configured using:
 'configure --with-ns '--enable-locallisppath=/Library/Application
 Support/Emacs/${version}/site-lisp:/Library/Application
 Support/Emacs/site-lisp' --with-modules 'CFLAGS=-DFD_SETSIZE=10000
 -DDARWIN_UNLIMITED_SELECT' --with-x-toolkit=no'

Configured features:
ACL GLIB GMP GNUTLS JPEG JSON LIBXML2 MODULES NOTIFY KQUEUE NS PDUMPER
PNG RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Text

Minor modes in effect:
  shell-dirtrack-mode: t
  auto-revert-mode: t
  server-mode: t
  override-global-mode: t
  delete-selection-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  column-number-mode: t
  line-number-mode: t
  auto-fill-function: do-auto-fill
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/Users/USERNAME/.emacs.d/lisp/dash hides
/Users/USERNAME/.emacs.d/elpa/dash-20221013.836/dash
/Users/USERNAME/.emacs.d/elpa/use-package-20221029.1857/use-package-jump
hides
/Applications/Emacs.app/Contents/Resources/lisp/use-package/use-package-jump
/Users/USERNAME/.emacs.d/elpa/use-package-20221029.1857/use-package-ensure
hides
/Applications/Emacs.app/Contents/Resources/lisp/use-package/use-package-ensure
/Users/USERNAME/.emacs.d/elpa/use-package-20221029.1857/use-package-core
hides
/Applications/Emacs.app/Contents/Resources/lisp/use-package/use-package-core
/Users/USERNAME/.emacs.d/elpa/use-package-20221029.1857/use-package-delight
hides
/Applications/Emacs.app/Contents/Resources/lisp/use-package/use-package-delight
/Users/USERNAME/.emacs.d/elpa/use-package-20221029.1857/use-package-diminish
hides
/Applications/Emacs.app/Contents/Resources/lisp/use-package/use-package-diminish
/Users/USERNAME/.emacs.d/elpa/use-package-20221029.1857/use-package hides
/Applications/Emacs.app/Contents/Resources/lisp/use-package/use-package
/Users/USERNAME/.emacs.d/elpa/use-package-20221029.1857/use-package-bind-key
hides
/Applications/Emacs.app/Contents/Resources/lisp/use-package/use-package-bind-key
/Users/USERNAME/.emacs.d/elpa/bind-key-20221028.1858/bind-key hides
/Applications/Emacs.app/Contents/Resources/lisp/use-package/bind-key
/Users/USERNAME/.emacs.d/elpa/use-package-20221029.1857/use-package-lint
hides
/Applications/Emacs.app/Contents/Resources/lisp/use-package/use-package-lint
/Users/USERNAME/.emacs.d/lisp/linum hides
/Applications/Emacs.app/Contents/Resources/lisp/obsolete/linum

Features:
(shadow mail-extr emacsbug dired-aux vc-hg vc-git diff-mode vc-bzr
vc-dispatcher misearch multi-isearch display-line-numbers
company-oddmuse company-keywords company-etags company-gtags
company-dabbrev-code company-dabbrev company-files company-clang
company-capf company-cmake company-semantic company-template
company-bbdb company tramp-cmds tramp-cache time-stamp tramp-sh tramp
tramp-loaddefs trampver tramp-integration files-x tramp-compat shell
parse-time iso8601 mm-archive message sendmail yank-media dired
dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 gnus-util
mailabbrev gmm-utils mailheader mm-decode mm-bodies mm-encode mail-utils
sort autorevert filenotify tango-theme server cmake-mode rst
persistent-todo todotxt rustic-spellcheck rustic-expand rustic-lsp
rustic-playpen rustic-rustfix rustic-racer etags fileloop xref
rustic-babel rustic-rustfmt project org-element org-persist org-id
org-refile avl-tree generator org ob ob-tangle ob-ref ob-lob ob-table
ob-exp org-macro org-src ob-comint org-pcomplete pcomplete org-list
org-footnote org-faces org-entities time-date ob-emacs-lisp ob-core
ob-eval org-cycle org-table ol org-fold org-fold-core org-keys oc
org-loaddefs find-func cal-menu calendar cal-loaddefs org-version
org-compat org-macs format-spec rustic-comint rustic-clippy rustic-doc
xdg f f-shortdoc shortdoc rustic-popup rustic-cargo rustic-compile
spinner s xterm-color markdown-mode color noutline outline icons
rustic-interaction rustic dash pcase use-package use-package-ensure
use-package-delight use-package-diminish use-package-bind-key bind-key
easy-mmode use-package-core rust-utils thingatpt rust-mode rx
rust-rustfmt rust-playpen rust-compile compile text-property-search
comint ansi-osc ansi-color ring rust-cargo gnutls network-stream
url-cache url-http url-auth mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr url-gw nsm puny epg-config finder-inf
special-scratch kmacro advice string-inflection cl-extra help-mode
desktop frameset unbound cl delsel auto-complete-autoloads
cmake-font-lock-autoloads cmake-mode-autoloads company-autoloads
fuzzy-autoloads popup-complete-autoloads popup-autoloads info package
browse-url url url-proxy url-privacy url-expand url-methods url-history
url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs password-cache
json subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs
cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/ns-win ns-win
ucs-normalize mule-util term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads kqueue cocoa ns multi-tty
make-network-process emacs)

Memory information:
((conses 16 415911 148371)
 (symbols 48 28452 0)
 (strings 32 147379 43984)
 (string-bytes 1 3839566)
 (vectors 16 54725)
 (vector-slots 8 1462349 223260)
 (floats 8 315 537)
 (intervals 56 738 0)
 (buffers 984 16))

[-- Attachment #2: Type: text/html, Size: 8579 bytes --]

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

[Eli Zaretskii]

> From: Duncan Greatwood <dgbulk@gmail.com>
> Date: Sat, 3 Aug 2024 12:54:01 -0700
> 
> 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’
> 
> Background:
> 
> I have a "Windows 11 Home Edition" remote machine, and am seeking to connect to that machine from emacs
> run on macOS.
> 
> In emacs, I am doing:
> (find-file "/ssh:WINUSERNAME@WIN11HOME:WINPATH")
> with suitable values for WINUSERNAME, WIN11HOME, WINPATH.
> 
> I can ssh to WIN11HOME (it is running the OpenSSH Server), using keys stored locally in my macOS.
> 
> 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". 
> 
> 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.
> 
> Thereafter, tramp produces the "uname/lisp" error above.
> 
> FYI, from the windows side:
>     sh-5.2$ uname -sr
>     MSYS_NT-10.0-22631 3.4.10-87d57229.x86_64

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.

Michael, am I right?

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.

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]

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.

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

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Duncan Greatwood <dgbulk@gmail.com>,  72450@debbugs.gnu.org
> Date: Sun, 04 Aug 2024 10:28:05 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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.

So Tramp expects to find 'uname' on a remote Windows system?  Does it
mean that one cannot login to a remote Windows system where 'uname' is
not available (it usually isn't)?

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

Sorry, no.  I don't have MSYS2 installed.  Could be actually Bash or
its customizations in the OP's init files.

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]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> 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.
>
> So Tramp expects to find 'uname' on a remote Windows system?  Does it
> mean that one cannot login to a remote Windows system where 'uname' is
> not available (it usually isn't)?

No. Tramp's implementation in tramp-sh.el, as used by the "ssh" method,
expects a Unixoid remote host, with a POSIX shell and several utilities
like 'uname'.

Accessing MS Windows systems is implemented by the "smb" method, using Samba.

Best regards, Michael.

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

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: dgbulk@gmail.com,  72450@debbugs.gnu.org
> Date: Sun, 04 Aug 2024 12:37:57 +0200
> 
> > So Tramp expects to find 'uname' on a remote Windows system?  Does it
> > mean that one cannot login to a remote Windows system where 'uname' is
> > not available (it usually isn't)?
> 
> No. Tramp's implementation in tramp-sh.el, as used by the "ssh" method,
> expects a Unixoid remote host, with a POSIX shell and several utilities
> like 'uname'.
> 
> Accessing MS Windows systems is implemented by the "smb" method, using Samba.

So I guess accessing Windows via ssh is not really supported, and the
OP should be advised to use "smb" instead?

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]

Eli Zaretskii <eliz@gnu.org> writes:

>> > So Tramp expects to find 'uname' on a remote Windows system?  Does it
>> > mean that one cannot login to a remote Windows system where 'uname' is
>> > not available (it usually isn't)?
>>
>> No. Tramp's implementation in tramp-sh.el, as used by the "ssh" method,
>> expects a Unixoid remote host, with a POSIX shell and several utilities
>> like 'uname'.
>>
>> Accessing MS Windows systems is implemented by the "smb" method, using Samba.
>
> So I guess accessing Windows via ssh is not really supported, and the
> OP should be advised to use "smb" instead?

It's preferable, yes. But I would wait for his comment, before we close
this bug.

Best regards, Michael.

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

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: dgbulk@gmail.com,  72450@debbugs.gnu.org
> Date: Sun, 04 Aug 2024 12:56:29 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > So I guess accessing Windows via ssh is not really supported, and the
> > OP should be advised to use "smb" instead?
> 
> It's preferable, yes. But I would wait for his comment, before we close
> this bug.

Sure, I didn't mean to suggest that we close this bug right away.

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

[Duncan Greatwood]

[-- Attachment #1: Type: text/plain, Size: 3877 bytes --]

Hi Michael and Eli -

Thanks for your comments so far.

I am not conscious of having installed any "special" MSYS(2)
components, nor have I consciously installed WSL. However, I have enabled
Developer Mode in Windows settings, which may have caused the installation
of this "sh".

In any case, regarding the versions of "sh" and "uname":

sh-5.2$ sh --version
GNU bash, version 5.2.26(1)-release (x86_64-pc-msys)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://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.
sh-5.2$
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).

Regarding using SMB, it is not super convenient in that i) the target
windows machine is not directly accessible right now, it is accessible via
an intervening ssh proxy; and ii) SMB seems pretty retro to me in 2024, but
maybe that's just me. However, for my personal purposes I could probably
figure out how to do SMB (e.g. something like
https://unix.stackexchange.com/questions/38099/have-samba-proxy-for-another-server,
or by setting up a VPN, or...). For additional background, Windows is
running as a KVM/QEMU VM on an Ubuntu machine; the Ubuntu machine is acting
as the ssh proxy, the Windows VM is directly accessible solely from the
Ubuntu machine; this is a common network configuration with VMs of course.

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.

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.

Best
-DG





On Sun, Aug 4, 2024 at 4:01 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Michael Albinus <michael.albinus@gmx.de>
> > Cc: dgbulk@gmail.com,  72450@debbugs.gnu.org
> > Date: Sun, 04 Aug 2024 12:56:29 +0200
> >
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> > > So I guess accessing Windows via ssh is not really supported, and the
> > > OP should be advised to use "smb" instead?
> >
> > It's preferable, yes. But I would wait for his comment, before we close
> > this bug.
>
> Sure, I didn't mean to suggest that we close this bug right away.
>

-- 
NOTICE: This email and its attachments may contain privileged and 
confidential information, only for the viewing and use of the intended 
recipient. If you are not the intended recipient, you are hereby notified 
that any disclosure, copying, distribution, acting upon, or use of the 
information contained in this email and its attachments is strictly 
prohibited and that this email and its attachments must be immediately 
returned to the sender and deleted from your system. If you received this 
email erroneously, please notify the sender immediately.  Xage Security, 
Inc. and its affiliates will never request personal information (e.g., 
passwords, Social Security numbers) via email.  Report suspicious emails to 
security-alerts@xage.com <mailto:security-alerts@xage.com>

[-- Attachment #2: Type: text/html, Size: 5886 bytes --]

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]

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.

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

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]

Andreas Schwab <schwab@suse.de> writes:

Hi Andreas,

>> 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.
>
> https://en.wikipedia.org/wiki/ANSI_escape_code#CSI_(Control_Sequence_Introducer)_sequences
>
> CSI H is cursor positioning, here row 17, column 120.

Thanks!

Best regards, Michael.

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

[Duncan Greatwood]

[-- Attachment #1: Type: text/plain, Size: 6032 bytes --]

Response below,

Thanks again.

On Mon, Aug 5, 2024 at 1:28 AM Michael Albinus <michael.albinus@gmx.de>
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.

[DG] Yes, makes sense.


> 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.
>
[DG] FWIW, I entered this command directly at the "sh" prompt on Windows,
and it looks OK AFAIK:
sh-5.2$ 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
///245adade605348c086dac6d8f612435c#$
///245adade605348c086dac6d8f612435c#$echo $TERM
dumb
///245adade605348c086dac6d8f612435c#$echo $INSIDE_EMACS
31.0.50,tramp:2.8.0-pre


>
> 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.
>
[DG] Fair enough.

On this basis, I configured a mount on the Linux machine of the Windows
share using cifs/smb. fstab entry thus:
//WINDOWS-IP/WINDOWS-SHARE-NAME LINUX-MOUNT-DIR cifs
credentials=CREDS-FOR-WINDOWS-STORED-IN-LINUX,rw,uid=1000,gid=1000,file_mode=0755,dir_mode=0755
0 0
(where 1000 is the UID and GID of my Linux user)

Then I used the normal tramp /ssh:... form to open LINUX-MOUNT-DIR and then
open a file contained on the mount. I.e. With emacs running on macOS, this
is going macOS -> (ssh) -> Linux -> (smb) -> Windows. And it seems to work
just as you'd hope.

So this seems to be an option for the use case of access via an SSH proxy,
provided the user has admin rights on the proxy (the Linux machine in this
case) to install on the proxy a CIFS mount of the Windows share.

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

I, along with many others, appreciate all your efforts.


>
>
> > 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.
>
[DG] Firstly, my apologies - I can't recreate the "uname parsing issue"
directly now. Instead, emacs will go to a time out trying to access the
Windows machine via the ssh proxy. I don't know what's changed.

In any case, I am enclosing the debug output file. It is 86MB, so I am
sharing via Google Drive, hopefully that's OK.
https://drive.google.com/file/d/1aH1c-58rfOmjKVBqqfJ9QpzY5m-ltmDQ/view?usp=sharing

This is with the Windows machine using /usr/bin/sh as the default shell for
ssh login. Confirmed at the client command prompt - if I do "ssh WINDOWS",
I log in and get the "sh" prompt.

>
> > Best
> > -DG
>
> Best regards, Michael.
>

-- 
NOTICE: This email and its attachments may contain privileged and 
confidential information, only for the viewing and use of the intended 
recipient. If you are not the intended recipient, you are hereby notified 
that any disclosure, copying, distribution, acting upon, or use of the 
information contained in this email and its attachments is strictly 
prohibited and that this email and its attachments must be immediately 
returned to the sender and deleted from your system. If you received this 
email erroneously, please notify the sender immediately.  Xage Security, 
Inc. and its affiliates will never request personal information (e.g., 
passwords, Social Security numbers) via email.  Report suspicious emails to 
security-alerts@xage.com <mailto:security-alerts@xage.com>

[-- Attachment #2: Type: text/html, Size: 8544 bytes --]

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]

Duncan Greatwood <dgreatwood@gmail.com> writes:

Hi Duncan,

> Then I used the normal tramp /ssh:... form to open LINUX-MOUNT-DIR and
> then open a file contained on the mount. I.e. With emacs running on
> macOS, this is going macOS -> (ssh) -> Linux -> (smb) -> Windows. And
> it seems to work just as you'd hope.

Good to know that you have a working solution.

>     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.
>
> [DG] Firstly, my apologies - I can't recreate the "uname parsing
> issue" directly now. Instead, emacs will go to a time out trying to
> access the Windows machine via the ssh proxy. I don't know what's
> changed.
>
> In any case, I am enclosing the debug output file. It is 86MB, so I am
> sharing via Google Drive, hopefully that's OK.
> https://drive.google.com/file/d/1aH1c-58rfOmjKVBqqfJ9QpzY5m-ltmDQ/view?usp=sharing
>
> This is with the Windows machine using /usr/bin/sh as the default
> shell for ssh login. Confirmed at the client command prompt - if I do
> "ssh WINDOWS", I log in and get the "sh" prompt.

According to the debug file, Tramp is blocked now at an earlier
stage. From your proxy host, it sends

--8<---------------cut here---------------start------------->8---
14:52:19.860849 tramp-send-command (6) # exec ssh -l dgrea -o ControlMaster=auto -o ControlPath=tramp.%C -o ControlPersist=no -e none WIN11_1HM
--8<---------------cut here---------------end--------------->8---

In its working buffer, it sees then after a timeout of one minute

--8<---------------cut here---------------start------------->8---
14:53:19.871637 tramp-process-actions (1) # File error: Timeout reached, see buffer ‘*tramp/ssh dgrea@WIN11_1HM*’ for details
tput: No value for $TERM and no -T specified
tput: No value for $TERM and no -T specified
[?25l[2J[m[Hsh-5.2$[1C]0;C:\Windows\system32\conhost.exe\a[?25h
--8<---------------cut here---------------end--------------->8---

The tput warnings can be ignored. But the last line is the shell prompt
offered to Tramp. It doesn't understand it.

Please read the Tramp manual, how to simplify the prompt in order to let
Tramp understand it. Escape sequences and a (Windows-syntax) path are
good to confuse Tramp.

Best regards, Michael.

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

[Duncan Greatwood]

[-- Attachment #1: Type: text/plain, Size: 4563 bytes --]

Thank you for reviewing the file.

Re:

> [?25l[2J[m[Hsh-5.2$[1C]0;C:\Windows\system32\conhost.exe [?25h


The actual prompt that appears on the screen is:
sh-5.2$

Please note that "C:\Windows\system32\conhost.exe" is not a prompt, it is
not output as text on the terminal, it is the "job name" that Windows
provides. (FYI, conhost.exe is the core Windows process that provides any
prompt, whether PowerShell, command prompt, or bash/sh).

As a point of comparison, when I ssh to a Linux machine the "job name" is
simply ssh.

I don't know why the string emacs-tramp is seeing as the prompt appears to
include the job name and those control characters. I have looked on client
side and server side, and don't see a way of suppressing/changing the job
name in Window's OpenSSH, nor the control characters either.

I tried it in iTerm and in Terminal. I tried it from macOS (with ssh proxy)
and from Linux (no proxy). All the same failure.

Unless there can be different handling in respect of the job name, I don't
see an approach to use ssh to access the windows box with tramp.

Unless you have any other suggestions :-)
Thanks again.




On Tue, Aug 6, 2024 at 12:41 AM Michael Albinus <michael.albinus@gmx.de>
wrote:

> Duncan Greatwood <dgreatwood@gmail.com> writes:
>
> Hi Duncan,
>
> > Then I used the normal tramp /ssh:... form to open LINUX-MOUNT-DIR and
> > then open a file contained on the mount. I.e. With emacs running on
> > macOS, this is going macOS -> (ssh) -> Linux -> (smb) -> Windows. And
> > it seems to work just as you'd hope.
>
> Good to know that you have a working solution.
>
> >     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.
> >
> > [DG] Firstly, my apologies - I can't recreate the "uname parsing
> > issue" directly now. Instead, emacs will go to a time out trying to
> > access the Windows machine via the ssh proxy. I don't know what's
> > changed.
> >
> > In any case, I am enclosing the debug output file. It is 86MB, so I am
> > sharing via Google Drive, hopefully that's OK.
> >
> https://drive.google.com/file/d/1aH1c-58rfOmjKVBqqfJ9QpzY5m-ltmDQ/view?usp=sharing
> >
> > This is with the Windows machine using /usr/bin/sh as the default
> > shell for ssh login. Confirmed at the client command prompt - if I do
> > "ssh WINDOWS", I log in and get the "sh" prompt.
>
> According to the debug file, Tramp is blocked now at an earlier
> stage. From your proxy host, it sends
>
> --8<---------------cut here---------------start------------->8---
> 14:52:19.860849 tramp-send-command (6) # exec ssh -l dgrea -o
> ControlMaster=auto -o ControlPath=tramp.%C -o ControlPersist=no -e none
> WIN11_1HM
> --8<---------------cut here---------------end--------------->8---
>
> In its working buffer, it sees then after a timeout of one minute
>
> --8<---------------cut here---------------start------------->8---
> 14:53:19.871637 tramp-process-actions (1) # File error: Timeout reached,
> see buffer ‘*tramp/ssh dgrea@WIN11_1HM*’ for details
> tput: No value for $TERM and no -T specified
> tput: No value for $TERM and no -T specified
> [?25l[2J[m[Hsh-5.2$[1C]0;C:\Windows\system32\conhost.exe [?25h
> --8<---------------cut here---------------end--------------->8---
>
> The tput warnings can be ignored. But the last line is the shell prompt
> offered to Tramp. It doesn't understand it.
>
> Please read the Tramp manual, how to simplify the prompt in order to let
> Tramp understand it. Escape sequences and a (Windows-syntax) path are
> good to confuse Tramp.
>
> Best regards, Michael.
>

-- 
NOTICE: This email and its attachments may contain privileged and 
confidential information, only for the viewing and use of the intended 
recipient. If you are not the intended recipient, you are hereby notified 
that any disclosure, copying, distribution, acting upon, or use of the 
information contained in this email and its attachments is strictly 
prohibited and that this email and its attachments must be immediately 
returned to the sender and deleted from your system. If you received this 
email erroneously, please notify the sender immediately.  Xage Security, 
Inc. and its affiliates will never request personal information (e.g., 
passwords, Social Security numbers) via email.  Report suspicious emails to 
security-alerts@xage.com <mailto:security-alerts@xage.com>

[-- Attachment #2: Type: text/html, Size: 6316 bytes --]

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

[Eli Zaretskii]

> From: Duncan Greatwood <dgreatwood@gmail.com>
> Date: Wed, 7 Aug 2024 14:46:29 -0700
> Cc: Eli Zaretskii <eliz@gnu.org>, dgbulk@gmail.com, 72450@debbugs.gnu.org
> 
> Re: 
> 
>  [?25l[2J[m[Hsh-5.2$[1C]0;C:\Windows\system32\conhost.exe [?25h
> 
> The actual prompt that appears on the screen is:
> sh-5.2$ 
> 
> Please note that "C:\Windows\system32\conhost.exe" is not a prompt, it is not output as text on the terminal, it
> is the "job name" that Windows provides. (FYI, conhost.exe is the core Windows process that provides any
> prompt, whether PowerShell, command prompt, or bash/sh).
> 
> As a point of comparison, when I ssh to a Linux machine the "job name" is simply ssh.
> 
> I don't know why the string emacs-tramp is seeing as the prompt appears to include the job name and those
> control characters. I have looked on client side and server side, and don't see a way of suppressing/changing
> the job name in Window's OpenSSH, nor the control characters either.
> 
> I tried it in iTerm and in Terminal. I tried it from macOS (with ssh proxy) and from Linux (no proxy). All the same
> failure.
> 
> Unless there can be different handling in respect of the job name, I don't see an approach to use ssh to
> access the windows box with tramp.

Maybe Tramp could recognize and ignore the cursor-motion parts?

Alternatively, file a bug to the MS-Windows terminal development team,
and ask them to provide at least optionally the standard behavior
exhibited by Posix platforms.

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]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

> Maybe Tramp could recognize and ignore the cursor-motion parts?

With the latest tests, we didn't reach the place Tramp could call
uname. It stops earlier with a shell propmt Tramp cannot understand;
don't know ehat has changed.

Best regards, Michael.

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

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Duncan Greatwood <dgreatwood@gmail.com>,  dgbulk@gmail.com,
>   72450@debbugs.gnu.org
> Date: Thu, 08 Aug 2024 13:06:14 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> Hi Eli,
> 
> > Maybe Tramp could recognize and ignore the cursor-motion parts?
> 
> With the latest tests, we didn't reach the place Tramp could call
> uname. It stops earlier with a shell propmt Tramp cannot understand;
> don't know ehat has changed.

But the "sh-5.2$" part of the prompt Tramp would have understood,
right?  I'm asking whether Tramp could ignore everything else in this
prompt, the part that is before "sh-5.2$" and the part after it?

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]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

> But the "sh-5.2$" part of the prompt Tramp would have understood,
> right?  I'm asking whether Tramp could ignore everything else in this
> prompt, the part that is before "sh-5.2$" and the part after it?

That's too tricky for Tramp's prompt detection. We must always make a
balance between a proper prompt regexp, and avoiding false positives.

Just ignoring everything before and after a fix string like "sh-5.2$" is
too risky. And I don't know whether it is worth the trouble. If it isn't
possible to configure the shell prompt, there might be more surprises
for Tramp.

Tramp requires a POSIX shell on the remote side. For good reasons.

Best regards, Michael.

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]

Duncan Greatwood <dgreatwood@gmail.com> writes:

Hi Duncan,

> Re:
>
>     [?25l[2J[m[Hsh-5.2$[1C]0;C:\Windows\system32\conhost.exe [?25h
>
> The actual prompt that appears on the screen is:
> sh-5.2$
>
> Please note that "C:\Windows\system32\conhost.exe" is not a prompt, it
> is not output as text on the terminal, it is the "job name" that
> Windows provides. (FYI, conhost.exe is the core Windows process that
> provides any prompt, whether PowerShell, command prompt, or bash/sh).
>
> As a point of comparison, when I ssh to a Linux machine the "job name"
> is simply ssh.
>
> I don't know why the string emacs-tramp is seeing as the prompt
> appears to include the job name and those control characters. I have
> looked on client side and server side, and don't see a way of
> suppressing/changing the job name in Window's OpenSSH, nor the control
> characters either.
>
> I tried it in iTerm and in Terminal. I tried it from macOS (with ssh
> proxy) and from Linux (no proxy). All the same failure.
>
> Unless there can be different handling in respect of the job name, I
> don't see an approach to use ssh to access the windows box with tramp.
>
> Unless you have any other suggestions :-)

As said, I know nothing about MS Windows specifics. But if the shell on
the remote side would be POSIX conform, setting PS1 a fixed string
should do the job. Perhaps there's somthing on the MS Windows side like
~/.profile, where you could add such setting.

> Thanks again.

Best regards, Michael.

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

[Jim Porter]

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.

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

[Duncan Greatwood]

[-- Attachment #1: Type: text/plain, Size: 4944 bytes --]

Jim - Yes that does sound similar.

All - I might try and register a bug/request with MSFT. If it's easy to do
so, are you able to point me to the POSIX requirement that specifies "If
TERM is set to "dumb", don't be prepending the prompt with the job name,
inserting control characters, or otherwise messing with it?"

If you understand my question.

Maybe MSFT can give a config option at least.
Thanks,
Duncan


On Thu, Aug 8, 2024 at 11:28 AM Jim Porter <jporterbugs@gmail.com> wrote:

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

-- 
NOTICE: This email and its attachments may contain privileged and 
confidential information, only for the viewing and use of the intended 
recipient. If you are not the intended recipient, you are hereby notified 
that any disclosure, copying, distribution, acting upon, or use of the 
information contained in this email and its attachments is strictly 
prohibited and that this email and its attachments must be immediately 
returned to the sender and deleted from your system. If you received this 
email erroneously, please notify the sender immediately.  Xage Security, 
Inc. and its affiliates will never request personal information (e.g., 
passwords, Social Security numbers) via email.  Report suspicious emails to 
security-alerts@xage.com <mailto:security-alerts@xage.com>

[-- Attachment #2: Type: text/html, Size: 6835 bytes --]

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]

Jim Porter <jporterbugs@gmail.com> writes:

Hi Jim,

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

I really appreciate the patches you and other guys have contributed. But
my point is different: Nobody has felt responsible over the last decades
to make MS Windows a first class citizen in Tramp. Personally, I canoot
and won't, since I don't use MS Windows.

It is different for other platforms. For example, there exist two
backends in Tramp for Android (tramp-adb.el and tramp-androidsu.el),
both contributed by other people.

I don't mean to criticize this lack of support. But it is an indication,
that there's no urgent need.

Best regards, Michael.