Subject: Re: grep's -m breaks -A
From: Jim Meyering <[email-masked]>
To: [email-masked]
Cc: Stepan Kasal <[email-masked]>, Kevin Brubeck Unhammer <[email-masked]>, Paul Eggert <[email-masked]>, Stuart MacDonald <[email-masked]>, Markus Jochim <[email-masked]>
Date: Sat, 25 Mar 2017 09:23:31 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

On Sat, Mar 25, 2017 at 12:12 AM, Stuart MacDonald
<[email-masked]> wrote:
> Follow-up Comment #3, bug #28588 (project grep):
>
> I just ran into this, trying to grep for the start of a problem in a 60 Gb
> syslog. :-(
>
> Context must always be printed; the current behaviour is unexpected,
> surprising, and counter-intuitive, says the lifetime unified diff user.

Please keep the discussion on the mailing list, not on that obsolete
tracker. I've added our bug-grep@ address, so this thread will
automatically get a new bug number in the debbugs-based tracker.

I responded to the OP back in 2010:

  https://lists.gnu.org/archive/html/bug-grep/2010-02/msg00002.html

Repeating part of that here, this behavior is documented, and now tested:

    `-m NUM'
    `--max-count=NUM'
         Stop reading a file after NUM matching lines.  If the input is
         standard input from a regular file, and NUM matching lines are
         output, `grep' ensures that the standard input is positioned just
         after the last matching line before exiting, regardless of the
         presence of trailing context lines.  This enables a calling
         process to resume a search.  For example, the following shell
         script makes use of it:

              while grep -m 1 PATTERN
              do
                echo xxxx
              done < FILE

Notice how it says grep takes care to position the standard input that
only the specified maximum number of matches are "read". This means
*not* printing all of the requested trailing context when that context
would contain any additional match.