Re: [PATCH] grep: add --max-count command line option

From: Paul Eggert <eggert@cs.ucla.edu>
Date: May 16, 2022, 07:28 UTC
Message-ID: <e89577f8-8f52-bf09-15f3-c534bf1a6c64@cs.ucla.edu>
In-Reply-To: <xmqqilq658b3.fsf@gitster.g>

On 5/15/22 22:57, Junio C Hamano wrote:

> It indeed is curious why GNU grep chose to immediately exit with 1
> when "-m 0" was given,

As I vaguely recall, if "-m 1" stops before "-m 2" does, then the idea was that it's reasonable for "-m 0" to stop before "-m 1" does, and the logical place to stop is right at the start, before any matches are found (i.e., exit with status 1).

What would be more useful for 'grep -m 0' to do? (Sorry, I came into this conversation just now.) Perhaps GNU 'grep -m 0' should change, if there's something better for it to do.

Show 5 quoted lines

> What "git grep -m -1" should do?  IIRC, OPT_INTEGER is for signed
> integer but the new .max_count member, as well as the existing
> "count" that is compared with it, are of "unsigned" type.  Either
> erroring out or treating it as unlimited is probably fine, but
> whatever we do, we should document and have a test for it.

'grep -m -1' treats the count as being unlimited, but this isn't documented and (from the code) appears to be accidental. It'd make sense for it to be documented.