GNU bug report logs - #26254
grep's -m breaks -A

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 26254 in the body.
You can then email your comments to 26254 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: bug-grep <at> gnu.org
Cc: Stepan Kasal <kasal <at> ucw.cz>, Kevin Brubeck Unhammer <unhammer <at> fsfe.org>,
 Paul Eggert <eggert <at> cs.ucla.edu>, Stuart MacDonald <stuartm.coding <at> gmail.com>,
 Markus Jochim <ich <at> markusjochim.de>
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
<INVALID.NOREPLY <at> 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.

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stuart MacDonald <stuartm.coding <at> gmail.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: Stepan Kasal <kasal <at> ucw.cz>, Paul Eggert <eggert <at> cs.ucla.edu>,
 Kevin Brubeck Unhammer <unhammer <at> fsfe.org>, bug-grep <at> gnu.org,
 26254 <at> debbugs.gnu.org, Markus Jochim <ich <at> markusjochim.de>
Subject: Re: grep's -m breaks -A
Date: Sat, 3 Jun 2017 09:59:00 -0400

[Message part 1 (text/plain, inline)]

I saw the documentation.

Thinking about this some time later, I've realised this is a no-win. Some
users will expect the context no matter what, since that's how context
works. Some users will need extra matching lines to absolutely not appear.
So making either option the default is wrong for someone. I think it needs
to be a parameter. Say
-F, --force-context
    Forces before (-B) after (-A) or both (-C) context to be output when
there are matching lines in the context window.

Thoughts?

...Stu

On Sat, Mar 25, 2017 at 12:23 PM, Jim Meyering <jim <at> meyering.net> wrote:

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

[Message part 2 (text/html, inline)]

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Nicholas Sushkin <nsushkin <at> openfinance.com>
To: stuartm.coding <at> gmail.com, bug-grep <at> gnu.org
Subject: bug#26254: grep's -m breaks -A
Date: Thu, 15 Jun 2017 10:09:52 -0400

[Message part 1 (text/plain, inline)]

I agree with Stu,

I wanted to see the first match of an Error in its context, so I used grep
-E Error -m 1 -C 10.
Grep didn't show the context after the match because there was another
match for Error right after the first.
I'd like to have an option to see the full context whether it has matches
or not.

ps. This is actually bug #28588 http://savannah.gnu.org/bugs/?28588
-- 

*Nicholas Sushkin*

[Message part 2 (text/html, inline)]

Message #17 received at 26254 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Nicholas Sushkin <nsushkin <at> openfinance.com>,
 Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 26254 <at> debbugs.gnu.org, Stuart MacDonald <stuartm.coding <at> gmail.com>
Subject: Re: bug#26254: grep's -m breaks -A
Date: Thu, 15 Jun 2017 21:58:05 -0700

On Thu, Jun 15, 2017 at 7:09 AM, Nicholas Sushkin
<nsushkin <at> openfinance.com> wrote:
> I agree with Stu,
>
> I wanted to see the first match of an Error in its context, so I used grep
> -E Error -m 1 -C 10.
> Grep didn't show the context after the match because there was another
> match for Error right after the first.
> I'd like to have an option to see the full context whether it has matches
> or not.
>
> ps. This is actually bug #28588 http://savannah.gnu.org/bugs/?28588

I am coming around... I think we may have been too hasty in making
this behavior the default. While I see how the current default can be
useful, that usage feels like it would be far less common than the
usage/expectation that provokes surprising (and likely to provoke
malfunction) behavior.

What do you think, Paul? Switch the default and add an option for the
current-default `--max-count=N`-trumps-`--context=N` behavior?

Message #20 received at 26254 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jim Meyering <jim <at> meyering.net>,
 Nicholas Sushkin <nsushkin <at> openfinance.com>
Cc: 26254 <at> debbugs.gnu.org, Stuart MacDonald <stuartm.coding <at> gmail.com>
Subject: Re: bug#26254: grep's -m breaks -A
Date: Sat, 17 Jun 2017 20:24:03 -0700

Jim Meyering wrote:
> What do you think, Paul? Switch the default and add an option for the
> current-default `--max-count=N`-trumps-`--context=N` behavior?

I am becoming inclined to change the behavior. That is, grep should consider 
--max-count=NUM to mean "only the first NUM matching lines count, as far as 
matches go". Any remaining lines do not match, by this definition.  This would 
change the behavior in the way that's being requested.

This would also change the meaning of grep -v --max-count=NUM, since NUM would 
count matches (which is what grep --help says) rather than non-matches. This 
would make grep and grep -v inverses as they probably should be even when -m is 
used.

Message #23 received at 26254 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jim Meyering <jim <at> meyering.net>,
 Nicholas Sushkin <nsushkin <at> openfinance.com>
Cc: 26254 <at> debbugs.gnu.org, Stuart MacDonald <stuartm.coding <at> gmail.com>
Subject: Re: bug#26254: grep's -m breaks -A
Date: Wed, 21 Jun 2017 14:10:29 -0700

[Message part 1 (text/plain, inline)]

On 06/17/2017 08:24 PM, Paul Eggert wrote:
>
> This would also change the meaning of grep -v --max-count=NUM

After looking into this, my proposal was too drastic. So I am attaching 
a more modest patch that would simply change grep's behavior along the 
lines requested. Athough this is an incompatible change, I think almost 
all users who care about it will prefer the new behavior. If there is a 
problem with it I suppose we could have an option to select the old 
behavior, but I hope it doesn't come to that.

[0001-grep-m-no-longer-cuts-off-trailing-context.patch (text/x-patch, attachment)]

Message #26 received at 26254 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 26254 <at> debbugs.gnu.org, Nicholas Sushkin <nsushkin <at> openfinance.com>,
 Stuart MacDonald <stuartm.coding <at> gmail.com>
Subject: Re: bug#26254: grep's -m breaks -A
Date: Wed, 21 Jun 2017 18:27:02 -0700

On Wed, Jun 21, 2017 at 2:10 PM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> On 06/17/2017 08:24 PM, Paul Eggert wrote:
>>
>>
>> This would also change the meaning of grep -v --max-count=NUM
>
>
> After looking into this, my proposal was too drastic. So I am attaching a
> more modest patch that would simply change grep's behavior along the lines
> requested. Athough this is an incompatible change, I think almost all users
> who care about it will prefer the new behavior. If there is a problem with
> it I suppose we could have an option to select the old behavior, but I hope
> it doesn't come to that.

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.

Message #31 received at 26254-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jim Meyering <jim <at> meyering.net>
Cc: 26254-done <at> debbugs.gnu.org, Nicholas Sushkin <nsushkin <at> openfinance.com>,
 Stuart MacDonald <stuartm.coding <at> gmail.com>
Subject: Re: bug#26254: grep's -m breaks -A
Date: Wed, 21 Jun 2017 19:01:41 -0700

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.

Message #34 received at 26254-done <at> debbugs.gnu.org (full text, mbox):

From: Stuart MacDonald <stuartm.coding <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 26254-done <at> debbugs.gnu.org, Nicholas Sushkin <nsushkin <at> openfinance.com>,
 Jim Meyering <jim <at> meyering.net>
Subject: Re: bug#26254: grep's -m breaks -A
Date: Thu, 22 Jun 2017 00:31:18 -0400

[Message part 1 (text/plain, inline)]

Looks good to me, but I'm not familiar with the code base. Thanks Paul.

...Stu

On Wed, Jun 21, 2017 at 10:01 PM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:

> 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.
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.