GNU bug report logs - #54487
29.0.50; connection-local value for `shell-file-name' not set in Dired buffers over Tramp

Previous Next

Full log

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

From: Jim Porter <jporterbugs <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; connection-local value for `shell-file-name' not set in
 Dired buffers over Tramp
Date: Sun, 20 Mar 2022 21:58:56 -0700

Hopefully I've summarized the issue correctly in the bug title. To see 
this in action, run the following from `emacs -Q' on an MS-Windows 
system ("host" in this example is a remote GNU/Linux system):

  C-x C-f /ssh:host:~
  M-x rgrep RET
  some text RET RET RET

The rgrep output will look something like:

  find [...] --null -e "some text" "{}" +
  find: paths must precede expression: `^^!^'

You can click the "[...]" to see the full invocation. However, even 
without doing that, if you look carefully, you'll notice that the 
shell-quoting uses the MS-Windows rules, not that of /bin/sh. For the 
MS-Windows shell, spaces are quoted by wrapping the entire argument in 
double-quotes ("like this"); for /bin/sh, spaces are escaped via a 
backslash (like\ this).

Presumably, that's because if you eval `shell-file-name' in the Dired 
buffer, it reports ".../path/to/cmdproxy.exe". When in a remote *file*, 
`shell-file-name' is correctly set to "/bin/sh".

This also comes up in other (non-Dired) situations. For example:

  C-x C-f /ssh:host:~/some-file.txt
  M-x rgrep RET
  some text RET RET RET
  ;; everything looks ok

  ;; now, from the rgrep buffer...
  M-x rgrep
  some text RET RET RET
  ;; same error as in the original case above

Previous Next

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