GNU bug report logs -
#54487
29.0.50; connection-local value for `shell-file-name' not set in Dired buffers over Tramp
Previous Next
Reported by: Jim Porter <jporterbugs <at> gmail.com>
Date: Mon, 21 Mar 2022 05:00:02 UTC
Severity: normal
Found in version 29.0.50
Fixed in version 29.1
Done: Michael Albinus <michael.albinus <at> gmx.de>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
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
This bug report was last modified 3 years and 56 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.