--- Begin Message ---
|
Subject: |
Re: 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.
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#26254: grep's -m breaks -A |
|
Date: |
Wed, 21 Jun 2017 19:01:41 -0700 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 |
On 06/21/2017 06:27 PM, Jim Meyering wrote:
Thanks for all of that careful work. It looks fine to me.
Please add a reference to this bug number, 26254, in the commit log.
Thanks, done.
--- End Message ---