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