On Sat, Mar 25, 2017 at 12:12 AM, Stuart MacDonald
<INVALID.NOREPLY@gnu.org> 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.