GNU bug report logs - #23451
25.0.93; Clarify the dependency on find/grep for platforms not having those tools

Previous Next

Package: emacs;

Reported by: Kaushal Modi <kaushal.modi <at> gmail.com>

Date: Wed, 4 May 2016 18:04:02 UTC

Severity: minor

Found in version 25.0.93

Done: Kaushal Modi <kaushal.modi <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #19 received at 23451 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: npostavs <at> users.sourceforge.net,Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 23451 <at> debbugs.gnu.org, drew.adams <at> oracle.com,
 Kaushal Modi <kaushal.modi <at> gmail.com>
Subject: Re: bug#23451: 25.0.93;
 Clarify the dependency on find/grep for platforms not having those
 tools
Date: Mon, 29 May 2017 07:19:46 +0300
On May 29, 2017 5:58:08 AM GMT+03:00, npostavs <at> users.sourceforge.net wrote:
>Dmitry Gutov <dgutov <at> yandex.ru> writes:
>
>> 4. See the user error about status 1, and the message containing four
>> grep hits. Doing this search with Ag confirms the same set of hits
>> (with normal exit status).
>>
>> Could someone please explain why find-grep exits with status 1 here?
>
>I see the same exit status when running find ... -exec grep ... + from
>the shell.  It seems that -exec <cmd> + will cause 'find' to exit with
>status 1 if the <cmd> exits with status 1:
>
>    ~$ find . -exec false '{}' + ; echo $?
>    1
>    ~$ find . -exec true '{}' + ; echo $?
>    0
>
>So when <cmd> is grep, and the number of files is greater than the
>command line length limit, the exit status is effectively random (it
>depends on 'find' decides to group the batches of files it passes to
>'grep').

Isn't this simply the consequence of grep returning non-zero status
for files that didn't match?




This bug report was last modified 7 years and 227 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.