Subject: bug#49229: closed (Re: bug#49229: 27.2; `M-x shell' fails over TRAMP from local MS Windows)

From: [email-masked] (GNU bug Tracking System)
Date: Mon, 28 Jun 2021 06:19:02 +0000

Your bug report

#49229: 27.2; `M-x shell' fails over TRAMP from local MS Windows

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
49229: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=49229
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#49229: 27.2; `M-x shell' fails over TRAMP from local MS Windows
From: Michael Albinus <[email-masked]>
To: Jim Porter <[email-masked]>
Cc: [email-masked]
Date: Mon, 28 Jun 2021 08:18:24 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

Version: 28.1

Jim Porter <[email-masked]> writes:

Hi Jim,

> This seems like a reasonable compromise to me. Like you say, it's not
> perfect, but it should at least prevent users from mistakenly entering
> local paths here.

I've pushed the patch to master, closing the bug. The Tramp part of the
patch will appear with Tramp 2.5.1 on GNU ELPA.

Best regards, Michael.

Subject: 27.2; `M-x shell' fails over TRAMP from local MS Windows
From: Jim Porter <[email-masked]>
To: [email-masked]
Date: Fri, 25 Jun 2021 16:05:57 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

(Note: I primarily tested on 27.2, but this doesn't look to be any
different on 28.0.50.) When invoking `M-x shell' over TRAMP from a
local MS Windows system, the default remote shell path is corrupted:

  emacs -Q
  C-x C-f /sshx:server:~/some/file.txt
  M-x shell
  ;; See the default prompt value:
  ;;   /sshx:server:/path/to/some//bin/sh
  ;; ("/path/to/some/" is greyed out)
  RET

The result is: "env: ‘c:/bin/sh’: No such file or directory". You can
also see this with the code used in `M-x shell' to get the remote
shell path:

  (read-file-name
   "Remote shell path: " default-directory shell-file-name
   t shell-file-name)

Eval'ing that from a TRAMP buffer and hitting RET returns "/bin/sh"
(i.e. `shell-file-name'); that is, we lost the TRAMP prefix, even
though the prompt made it look like we'd keep it. If you edit the path
to, say, "/sshx:server:/path/to/some//usr/bin/zsh" and hit RET, the
result is "/sshx:server:/usr/bin/zsh", which is good. The result of
this call is then passed to `expand-file-name', which on MS Windows,
turns "/bin/sh" into "c:/bin/sh". Finally, that gets called on the
remote (running GNU/Linux), and things break.

I've attached a WIP patch that resolves this, but I don't think it's
quite right (hence, I didn't use `git format-patch'). This seems to be
more of an issue with `read-file-name' not being smart enough; even if
we set the `default-filename' argument to nil, the default return
value is still a local (non-TRAMP) path, which isn't right. Since
`read-file-name' is better able to tell whether the user wanted the
default value or they specifically wanted a local shell, it might be
better to fix the issue there. However, that's a pretty widely-used
function, and I'm hesitant to change the behavior in
potentially-breaking ways.

If the current WIP patch does look good though, I can clean it up (add
a comment and a commit message) for it to be merged. Or I can try to
fix `read-file-name' if there's agreement about how it should work in
this case.