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

Previous Next

Full log

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

From: Duncan Greatwood <dgreatwood <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: dgbulk <at> gmail.com, Michael Albinus <michael.albinus <at> gmx.de>,
 72450 <at> debbugs.gnu.org
Subject: Re: bug#72450: 29.1; Tramp Failed to Parse OS Name and Version for
 Windows 11
Date: Sun, 4 Aug 2024 20:39:19 -0700

[Message part 1 (text/plain, inline)]

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 <at> gnu.org> wrote:

> > From: Michael Albinus <michael.albinus <at> gmx.de>
> > Cc: dgbulk <at> gmail.com,  72450 <at> debbugs.gnu.org
> > Date: Sun, 04 Aug 2024 12:56:29 +0200
> >
> > Eli Zaretskii <eliz <at> 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 <at> xage.com <mailto:security-alerts <at> xage.com>

[Message part 2 (text/html, inline)]

Previous Next

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