From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alex Schroeder via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#66338: 30.0.50; grep-commnd set and using an old fish results in empty Copyright files Date: Wed, 04 Oct 2023 20:47:35 +0200 Message-ID: <871qeajkc8.fsf@alexschroeder.ch> References: <87cyxu66mw.fsf@alexschroeder.ch> Reply-To: Alex Schroeder Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24824"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dmitry@gutov.dev, 66338@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Oct 04 21:08:58 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qo7Ev-000657-Na for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 04 Oct 2023 21:08:58 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qo7El-0005Cl-GZ; Wed, 04 Oct 2023 15:08:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qo7Ej-0005B2-AX for bug-gnu-emacs@gnu.org; Wed, 04 Oct 2023 15:08:45 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qo7Ei-0005Cx-V0 for bug-gnu-emacs@gnu.org; Wed, 04 Oct 2023 15:08:44 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qo7F0-0000gl-Ag for bug-gnu-emacs@gnu.org; Wed, 04 Oct 2023 15:09:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alex Schroeder Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 04 Oct 2023 19:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66338 X-GNU-PR-Package: emacs Original-Received: via spool by 66338-submit@debbugs.gnu.org id=B66338.16964465142597 (code B ref 66338); Wed, 04 Oct 2023 19:09:02 +0000 Original-Received: (at 66338) by debbugs.gnu.org; 4 Oct 2023 19:08:34 +0000 Original-Received: from localhost ([127.0.0.1]:45406 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qo7EQ-0000fh-LB for submit@debbugs.gnu.org; Wed, 04 Oct 2023 15:08:34 -0400 Original-Received: from out-195.mta0.migadu.com ([91.218.175.195]:50467) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qo6uc-0008SB-5d for 66338@debbugs.gnu.org; Wed, 04 Oct 2023 14:47:59 -0400 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alexschroeder.ch; s=key1; t=1696445258; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to; bh=9nWyH2rC8PT1qZ3v69H0mnRniprqpVo7lF9o9IT1sYo=; b=fLInYcYgfaExbG/4F7u3n13C4+Cfrr3vP3Ju4WRIztoj8JnsjYTsCLfVWcnt1Yma2MC9WK siG+v+pNnq6+ERvx6FDP6CFX46DtwV15rHlWupchBWPhVJSjEk/kuHnVJL1cuZW394U+rx MvNAMM5NniZQTas6PqL2KqPwulNrJyAPav0nQcFj1SuQqXeNhYzooBpUNf/KA7KhXdcpYZ LuOHh5Q0pG59FlEDJc2ZczUd+fqbIwE9s1WQbK+YYftDqhQRuxzcKGlwGTl5WsN8QfVK5a 2JnNO4GIuW7/caP3uv1CnCZTzDbzCFiIK7ab1gpUmfj1MlzJH/OtMjEPYvfJJw== In-Reply-To: <83a5sy5o01.fsf@gnu.org> (message from Eli Zaretskii on Wed, 04 Oct 2023 19:52:14 +0300) X-Migadu-Flow: FLOW_OUT X-Mailman-Approved-At: Wed, 04 Oct 2023 15:08:25 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:271822 Archived-At: Eli Zaretskii writes: >> From: Dmitry Gutov >>=20 >> 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 =E2=86=92 connection-local-profile-alist =E2=86=92 tramp-connection-local-default-shell-profile =E2=86=92 shell-file-name =E2= =86=92 "/bin/sh". So I don=E2=80=99t 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=E2=80=99t 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=E2=80=99d 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