GNU bug report logs - #49229
27.2; `M-x shell' fails over TRAMP from local MS Windows

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Jim Porter <jporterbugs <at> gmail.com>
Subject: bug#49229: closed (Re: bug#49229: 27.2; `M-x shell' fails over
 TRAMP from local MS Windows)
Date: Mon, 28 Jun 2021 06:19:02 +0000

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

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 49229 <at> debbugs.gnu.org.

-- 
49229: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=49229
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 49229-done <at> debbugs.gnu.org
Subject: Re: bug#49229: 27.2; `M-x shell' fails over TRAMP from local MS
 Windows
Date: Mon, 28 Jun 2021 08:18:24 +0200

Version: 28.1

Jim Porter <jporterbugs <at> gmail.com> 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.

[Message part 3 (message/rfc822, inline)]

From: Jim Porter <jporterbugs <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.2; `M-x shell' fails over TRAMP from local MS Windows
Date: Fri, 25 Jun 2021 16:05:57 -0700

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

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

[shell-tramp.patch (application/octet-stream, attachment)]

Previous Next

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