bug#66338: 30.0.50; grep-commnd set and using an old fish results in empty Copyright files

[Alex Schroeder via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dmitry Gutov <dmitry@gutov.dev>
>> 
>> Perhaps the problem is that you changed shell-file-name to point to
>> fish?
>
> Exactly. And that is never a good idea, because we use the semantics
> of Bourne shell in these cases.

Well, it is set, but not by me. I checked using the following:

find ~/.emacs.d -name '*.el' -exec grep -H shell-file-name '{}' ';'

There are a few matches in magit, and a single match in my init.el file
where it is part of a huge custom-set-variables →
connection-local-profile-alist →
tramp-connection-local-default-shell-profile → shell-file-name →
"/bin/sh". So I don’t set it to "/usr/bin/fish" myself.

When I start emacs -Q from my terminal emulator, I get an Emacs that has
shell-file-name set to "/usr/bin/fish".

The doc string says that shell-file-name is based on the SHELL
environment variable. That variable is of course set to /usr/bin/fish.

It seems to me that if it so important that Bourne shell semantics be
used, either shell-file-name should not be set automatically, or it
should be temporarily overridden in the cases where we rely on Bourne
shell semantics, or a warning should be printed whenever such code sees
a shell name it doesn’t know to be compatible with (although the
required fixes by a user like me would seem to be many and confusing).

From my point of view, it seems that manually setting shell-file-name to
"/bin/sh" is the only realistic solution and therefore I’d say that
setting this variable from the SHELL environment variable seems like the
wrong thing to do for Emacs. Is there a scenario where this is a good
idea?

For interactive use like M-x shell we already use
explicit-shell-file-name which is based on ESHELL or shell-file-name.
Perhaps that variable should be based on ESHELL, SHELL, and only use
shell-file-name as a last resort and we no longer set shell-file-name
based on the SHELL variable.

Instead, shell-file-name should be set based on a list of known,
compatible shells available, or remain unset and all commands that rely
on it should fail gracefully and inform the user if no compatible shell
was found.

What do you think?

Cheers
Alex