[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#26254: grep's -m breaks -A
From: |
Jim Meyering |
Subject: |
bug#26254: grep's -m breaks -A |
Date: |
Sat, 25 Mar 2017 09:23:31 -0700 |
On Sat, Mar 25, 2017 at 12:12 AM, Stuart MacDonald
<address@hidden> 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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#26254: grep's -m breaks -A,
Jim Meyering <=