From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#68864: 30.0.50; project-find-regexp fails on Alpine Date: Thu, 1 Feb 2024 22:54:53 +0200 Message-ID: References: <87eddw3lch.fsf@pub.pink> <74014cf8-3299-44ad-85bd-e9f9981c66e7@gutov.dev> <87o7d0vvk8.fsf@pub.pink> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27718"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: 68864@debbugs.gnu.org To: john muhl Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Feb 01 21:56:12 2024 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 1rVe6V-00070Y-Lp for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 01 Feb 2024 21:56:12 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rVe6E-0003Gv-FD; Thu, 01 Feb 2024 15:55:54 -0500 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 1rVe6D-0003GZ-22 for bug-gnu-emacs@gnu.org; Thu, 01 Feb 2024 15:55:53 -0500 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 1rVe6C-0002Oi-LW for bug-gnu-emacs@gnu.org; Thu, 01 Feb 2024 15:55:52 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rVe6M-0002x2-B4 for bug-gnu-emacs@gnu.org; Thu, 01 Feb 2024 15:56:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 01 Feb 2024 20:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68864 X-GNU-PR-Package: emacs Original-Received: via spool by 68864-submit@debbugs.gnu.org id=B68864.170682092411280 (code B ref 68864); Thu, 01 Feb 2024 20:56:02 +0000 Original-Received: (at 68864) by debbugs.gnu.org; 1 Feb 2024 20:55:24 +0000 Original-Received: from localhost ([127.0.0.1]:43220 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rVe5j-0002vq-OT for submit@debbugs.gnu.org; Thu, 01 Feb 2024 15:55:24 -0500 Original-Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:44939) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rVe5b-0002vB-C2 for 68864@debbugs.gnu.org; Thu, 01 Feb 2024 15:55:22 -0500 Original-Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.west.internal (Postfix) with ESMTP id CE6D23200AC1; Thu, 1 Feb 2024 15:54:56 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 01 Feb 2024 15:54:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1706820896; x=1706907296; bh=hNey51hfmTn8TpKfOK7twkjNiYY6deQBrWxycs0yL4U=; b= ObFKq/dmy29FY7c/mT/MHfTzvKeEoAZV6aLlzn6pbUyyDLYe/ZT7DcjZE0nGLv1G +JddScb2v5z4XRqV/vIZC/MBwoUEmHAYt/iqTuwQqMWLURlChgZAHGPMxboKvKM2 23cmXeOaJetp3udQtxFnYasOzQV80ueNUF/FjUrUM3BBaACmASpeRYyMLDmEEek/ eao+PwVv368c4vClk3GqBqk3vnYCaHj3WUwK1wixJ2yPBhxZK+Uv21tQkQeSTTkX WZnHBOmgVw478o0pfPiVdIEUmaYvUvba74M5Mq6oIWjIEo9UETiRBYZz39ZMlEPc TfVI/pZoc4lYkTYbmDSujw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1706820896; x= 1706907296; bh=hNey51hfmTn8TpKfOK7twkjNiYY6deQBrWxycs0yL4U=; b=P vDni73o4lLxsDr5H0nGkUPGh4k2ZEgggqO3x1J0No7ivi21kC6j/i7J1eFXBBdlW 31TRAfjb4TN7FztjcQHJ1caWvT3z6wSxf8bnw142JfJJ7iuXbXd8wehekbo9kt8b jABlTbObVgiABYkIS8puBr9BvyPG/G4dSBgt1l6pEzmoGeIoLO5U6bJzSBYkx2S0 rXLnXtqtjFu5xhMrg4vABAIzPw4brmqq53RgcX/lOdm+zuVL6rV6s4QvQOhe+1nj IPnodme8qyHg+PDUMa+TNYcBaYhHASrblkBQZfi8dgaraq8f13vs9oVpRBATnoUM CdaJO8D3cCG0mjDmjyIiA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrfeduuddgudefkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthekredttddvjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeeigfehjefhheekgfehtdeljeeiveefteegveekuefgvdeivdejveefgfdu vdfhieenucffohhmrghinhepsghogihmrghtrhhigidrihhnfhhopdhophgvnhgsshgurd horhhgpdgsuhhshigsohigrdhnvghtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 1 Feb 2024 15:54:54 -0500 (EST) Content-Language: en-US In-Reply-To: <87o7d0vvk8.fsf@pub.pink> 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:279306 Archived-At: On 01/02/2024 19:13, john muhl wrote: > Dmitry Gutov writes: > >> On 01/02/2024 05:38, john muhl via Bug reports for GNU Emacs, the >> Swiss army knife of text editors wrote: >>> The grep on Alpine does not support the --null option. >>> $ grep --null test * >>> grep: unrecognized option: null >>> BusyBox v1.36.1 (2024-01-16 17:10:30 UTC) multi-call binary. >>> To reproduce: >>> emacs -Q >>> M-: (project-find-regexp "test") >>> Debugger entered--Lisp error: (user-error "Search failed with status >>> 123: grep: unrecognized option: null") >>> signal(user-error ("Search failed with status 123: grep: unrecognized option: null")) >> >> Hi! >> >> That's a problem: apparently it does indeed not support --null or -Z: >> https://boxmatrix.info/wiki/Property:grep >> >> There is another flag we could use, which seems to have a similar >> enough effect: -z. But from what I can tell, it would make OpenBSD >> unsupported: https://man.openbsd.org/grep > > Even -z is a compile time option: > > $ busybox grep -h > BusyBox v1.36.1 (2024-01-16 17:10:30 UTC) multi-call binary. > > Usage: grep [-HhnlLoqvsrRiwFE] [-m N] [-A|B|C N] … > > https://git.busybox.net/busybox/tree/findutils/grep.c#n85 That's... unexpected. > I couldn’t get busybox to compile with the EXTRA_COMPAT option > so can’t say if it helps or not. > >> Perhaps it would be best to just file a feature request for busybox's >> support for --null/-Z. Better ideas welcome. >> >> In the meantime, you can customize the entry for 'grep' in >> xref-search-program-alist to use -z. > > Would it be possible to have xref check > grep-use-null-filename-separator and only use --null when > available? I tried with this crude patch and the results look > good enough: > > --- a/lisp/progmodes/xref.el > +++ b/lisp/progmodes/xref.el > @@ -1855,7 +1855,11 @@ xref-search-program-alist > `((grep > . > ;; '-s' because 'git ls-files' can output broken symlinks. > - ,(concat "xargs -0 " xargs-max-chars "grep --null -snHE -e ")) > + ,(concat "xargs -0 " xargs-max-chars "grep " > + (when (and (grep-compute-defaults) > + grep-use-null-filename-separator) > + " --null") > + " -snHE -e ")) > (ripgrep > . > ;; '!*/' is there to filter out dirs (e.g. submodules). That would slow down the loading of xref.el, which seems unfortunate, even if it's only by 0.05s (just measured on my machine; on many others it will be more). What we could do, I suppose, is check whether grep-use-null-filename-separator is set to some explicit value (not 'auto-detect'), and if so, apply it. That would work if xref.el is loaded late, or if you customized the variable explicitly. I was also thinking of adding another template parameter like , but it would be used for 'grep'--would seem odd. We also could just remove "--null" inside xref-matches-in-files from grep's command line if the variable is set to this or that. It would be unfortunate to encounter some false positives, though (though I can't imagine them now).