On Sat, Mar 25, 2017 at 12:12 AM, Stuart MacDonald <invalid.nore...@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.
