Subject: bug#54487: closed (Re: bug#54487: 29.0.50; connection-local value for `shell-file-name' not set in Dired buffers over Tramp)

From: [email-masked] (GNU bug Tracking System)
Date: Wed, 23 Mar 2022 11:54:02 +0000

Your bug report

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

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

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

Subject: Re: bug#54487: 29.0.50; connection-local value for `shell-file-name' not set in Dired buffers over Tramp
From: Michael Albinus <[email-masked]>
To: Jim Porter <[email-masked]>
Cc: Eli Zaretskii <[email-masked]>, [email-masked]
Date: Wed, 23 Mar 2022 12:53:08 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

Version: 29.1

Michael Albinus <[email-masked]> writes:

Hi Jim,

> For the scope of this bug report, it could be closed. But I'll like to
> keep it open for now in order to discuss possible problems with the
> connection-local variables approach.

I've checked the needed changes, and it would be too invasive. In
grep.el, host specific settings are computed by global variables.
Furthermore, the compilation buffer is created only after computing
these settings.

This would require a larger rewrite of grep.el. I believe it isn't worth then.

Closing the bug.

Best regards, Michael.

Subject: 29.0.50; connection-local value for `shell-file-name' not set in Dired buffers over Tramp
From: Jim Porter <[email-masked]>
To: [email-masked]
Date: Sun, 20 Mar 2022 21:58:56 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

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