unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Michael Albinus <michael.albinus@gmx.de>
To: Jim Porter <jporterbugs@gmail.com>
Cc: 54487@debbugs.gnu.org
Subject: bug#54487: 29.0.50; connection-local value for `shell-file-name' not set in Dired buffers over Tramp
Date: Tue, 22 Mar 2022 10:44:04 +0100	[thread overview]
Message-ID: <878rt2pbiz.fsf@gmx.de> (raw)
In-Reply-To: <2004fb45-f690-5fa2-be48-f9c1b7f970f9@gmail.com> (Jim Porter's message of "Mon, 21 Mar 2022 11:04:32 -0700")

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.





  reply	other threads:[~2022-03-22  9:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-21  4:58 bug#54487: 29.0.50; connection-local value for `shell-file-name' not set in Dired buffers over Tramp Jim Porter
2022-03-21 10:25 ` Michael Albinus
2022-03-21 12:40   ` Eli Zaretskii
2022-03-21 14:06     ` Michael Albinus
2022-03-21 14:52       ` Eli Zaretskii
2022-03-21 15:02         ` Michael Albinus
2022-03-21 15:05           ` Eli Zaretskii
2022-03-21 15:09             ` Michael Albinus
2022-03-21 18:04       ` Jim Porter
2022-03-22  9:44         ` Michael Albinus [this message]
2022-03-23 11:53           ` Michael Albinus
2022-03-23 16:55             ` Jim Porter
2022-03-23 18:58         ` Michael Albinus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878rt2pbiz.fsf@gmx.de \
    --to=michael.albinus@gmx.de \
    --cc=54487@debbugs.gnu.org \
    --cc=jporterbugs@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).