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

[Michael Albinus]

Jim Porter <jporterbugs@gmail.com> writes:

Hi Jim,

> On 3/21/2022 7:06 AM, Michael Albinus wrote:
>> I'll wait until Jim confirms that this works in general, then I would
>> apply a patch along this spec.

I've pushed a fix to master. It is different from what I have shown
before, but shall serve as well.

> The patch you posted works for me. Setting `shell-file-name' to
> "/bin/sh" worked in my tests because it makes the function
> `w32-shell-dos-semantics' return nil, so this condition in
> `shell-quote-argument' isn't matched:
>
>   ((and (eq system-type 'windows-nt) (w32-shell-dos-semantics))
>
> That makes the shell-quoting use POSIX-style rules instead, which is
> what we want if the default-directory is remote. Reading that code, I
> think the `w32-shell-dos-semantics' part of that condition is there to
> handle things like Cygwin builds, so maybe it's not quite right to
> rely on that for the case I described in the original report. (That
> said, I think it would only be an issue for some truly esoteric
> configurations.)

Fiddling with shell-file-name doesn't help in this case, because
connection-local variables are not applied in every remote buffer, like
in dired buffers. The more general collection of Tramp-aware
connection-local variables could damage something else, that's why it is
appled on programmatic request only.

> On the other hand, I think I like the idea of having grep be aware of
> connection-local variables even better. That's more flexible, and also
> should work for the reverse case: if you call rgrep from a Tramp file
> buffer, but change the search directory to a local path, rgrep uses
> POSIX shell-quoting. It should use MS-Windows shell-quoting in that
> case (since it's running the command on the local Windows system).

Yep, I'll start now to work on this. The plan is to collect these
specific connection-local variables in an own :application, so that they
are set only with the given "grep" scope.

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.

Best regards, Michael.