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

[Eli Zaretskii]

> From: Alex Schroeder <alex@alexschroeder.ch>
> Cc: dmitry@gutov.dev, 66338@debbugs.gnu.org
> Date: Wed, 04 Oct 2023 20:47:35 +0200
> 
> 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 should be only set in interactive sessions.  Please review your
system init files, and modify them so that you override the default
value of SHELL only in interactive sessions.

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

The Emacs manual says:

  ‘SHELL’
       The name of an interpreter used to parse and execute programs run
       from inside Emacs.  This is used to initialize the variable
       ‘shell-file-name’ (*note Single Shell::).

So Emacs expects this variable to point to a shell that Emacs can use
to run programs, not your interactive shell.  If you want a different
shell to be used in interactive shell sessions, such as "M-x shell",
then you should use the variable explicit-shell-file-name to point to
that other shell (in your case, fish).

> 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?

I think we already have the facilities to configure this as needed,
see above.