GNU bug report logs - #31537
Combining -v and -A/-B/-C options

Previous Next

Package: grep;

Reported by: "Garreau\, Alexandre" <galex-713 <at> galex-713.eu>

Date: Sun, 20 May 2018 01:58:02 UTC

Severity: wishlist

Tags: notabug

To reply to this bug, email your comments to 31537 AT debbugs.gnu.org.

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-grep <at> gnu.org:
bug#31537; Package grep. (Sun, 20 May 2018 01:58:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Garreau\, Alexandre" <galex-713 <at> galex-713.eu>:
New bug report received and forwarded. Copy sent to bug-grep <at> gnu.org. (Sun, 20 May 2018 01:58:02 GMT) Full text and rfc822 format available.

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

From: "Garreau\, Alexandre" <galex-713 <at> galex-713.eu>
To: bug-grep <at> gnu.org
Subject: Combining -v and -A/-B/-C options
Date: Sun, 20 May 2018 03:15:43 +0200
[Message part 1 (text/plain, inline)]
It seems using a context option (-A (after-), -B (before-) or -C
(context)) when -v (invert-match) is in use just do nothing as well as
disabling the later.  I don’t see the utility of this behavior, as well
as I didn’t see it documented anywhere in the description of any of
these options.

I believe context options used in conjonction with invert-match option
should specify which lines *not to show* along with matched then not
shown lines.

For instance, while this command:
[without-2.sh (text/x-sh, inline)]
seq 1 100 | grep -v '2$'
[Message part 3 (text/plain, inline)]
does show the list of numbers going from 1 to 100, without those ending
with “2” in base 10, this one:
[without-2-and-3.sh (text/x-sh, inline)]
seq 1 100 | grep -v '2$' -A 1
[Message part 5 (text/plain, inline)]
should also hide the lines ending with “3” because they systematically
follow those ending with “2” (currently it just show all the numbers
from 1 to 100).

I didn’t look at if grep does act differently according the order
options are given, but if so maybe this behavior could be triggered only
if the context option were specified *after* the invert-match one?

Thank you for any attention!

Information forwarded to bug-grep <at> gnu.org:
bug#31537; Package grep. (Mon, 21 May 2018 01:04:01 GMT) Full text and rfc822 format available.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: "Garreau, Alexandre" <galex-713 <at> galex-713.eu>, 31537 <at> debbugs.gnu.org
Subject: Re: bug#31537: Combining -v and -A/-B/-C options
Date: Sun, 20 May 2018 18:03:04 -0700
Garreau, Alexandre wrote:
> I believe context options used in conjonction with invert-match option
> should specify which lines*not to show*  along with matched then not
> shown lines.

I can see it the other way. For example, "show all lines that lack signed 
integers, plus their context" can be done via a command like "grep -C1 -v -E 
'[-+][0-9]+([^.e]|$)'", and I don't see any easy way to do the same search under 
the changes you're proposing.

In essence you're proposing a new feature that I'd call "negative context"; 
i.e., if a line is not selected, then suppress the output of nearby lines that 
are selected. grep already has a lot of features and it's not clear this one is 
important enough to add.

> maybe this behavior could be triggered only
> if the context option were specified *after* the invert-match one

I'd prefer option order to not matter, at least when options do not simply 
override each other (as is the case here).




Information forwarded to bug-grep <at> gnu.org:
bug#31537; Package grep. (Mon, 21 May 2018 06:43:02 GMT) Full text and rfc822 format available.

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

From: "Garreau\, Alexandre" <galex-713 <at> galex-713.eu>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 31537 <at> debbugs.gnu.org
Subject: Re: bug#31537: Combining -v and -A/-B/-C options
Date: Mon, 21 May 2018 08:42:42 +0200
[Message part 1 (text/plain, inline)]
Le 20/05/2018 à 18h03, Paul Eggert a écrit :
> Garreau, Alexandre wrote:
>> I believe context options used in conjonction with invert-match option
>> should specify which lines*not to show*  along with matched then not
>> shown lines.
>
> I can see it the other way. For example, "show all lines that lack
> signed integers, plus their context" can be done via a command like
> "grep -C1 -v -E 
> '[-+][0-9]+([^.e]|$)'", and I don't see any easy way to do the same
> search under the changes you're proposing.

Oh in fact, I didn’t notice it actually had this effect… in fact when
only a few lines don’t match, especially when they’re not contiguous,
using -v with context options nearly equals not using grep at all… turns
out I narrowed enough my mind to miss this.

> In essence you're proposing a new feature that I'd call "negative
> context"; i.e., if a line is not selected, then suppress the output of
> nearby lines that are selected. grep already has a lot of features and
> it's not clear this one is important enough to add.

My memory is bad, but grepping at looking at my history for when I made
up this example says me I needed this feature for something like this:
[apt.sh (text/x-sh, inline)]
apt search programming ant | grep -v '^lib' -A 2 | less
[Message part 3 (text/plain, inline)]
Here I guess we’re in a case where sed would be better suited… like a
bunch of today’s features of grep (invert-match, personally I believe it
would naturally be handy with it): they both come from ed
after all. But this seems to be, as coincidently said today on #emacs
(and later outside I heard [1]), a case of:
[opposite.log (text/plain, inline)]
[CEST]
[03:16:37] <JordiGH> Don't you love it when you have commands like
[03:16:54] <JordiGH> do_the_thing --nope-this-option-makes-me-do-the-opposite-of-the-thing
[03:17:00] <JordiGH> Currently thinking of
[03:17:07] <JordiGH> ssh-keygen -R
[03:17:13] <chu> It's the Unix way
[03:17:14] <JordiGH> That -R makes it delete a key instead of generating one.
[03:17:55] <twb> ssh-keygen is a random grab-bag utility that does lots of things, and yes, it's dumb
[03:18:13] <JordiGH> It's the git way.
[03:19:16] <JordiGH> sort --random-sort
[…]
[03:19:24] <JordiGH> Isn't that, like, the opposite of sorting?
[PS : JordiGH agreed to be quoted in pm, and before that]
[06:37:04] <galex-713> twb: can I quote you too?
[06:38:11] <galex-713> chu: what about you then, too?
[06:38:41] <twb> galex-713: sure, you can quote that
[08:20:01] <chu> galex-713: it's fine
[Message part 5 (text/plain, inline)]
>> maybe this behavior could be triggered only
>> if the context option were specified *after* the invert-match one
>
> I'd prefer option order to not matter, at least when options do not
> simply override each other (as is the case here).

Agree, would add more complexity of use. And keywords are made to get
rid of order considerations anyway.

[1] Unix options that make commands do the opposite of their name: <https://mathstodon.xyz/@JordiGH/100064804426272107>

Severity set to 'wishlist' from 'normal' Request was from Paul Eggert <eggert <at> cs.ucla.edu> to control <at> debbugs.gnu.org. (Wed, 01 Jan 2020 07:43:01 GMT) Full text and rfc822 format available.

Added tag(s) notabug. Request was from Paul Eggert <eggert <at> cs.ucla.edu> to control <at> debbugs.gnu.org. (Wed, 01 Jan 2020 07:43:01 GMT) Full text and rfc822 format available.

This bug report was last modified 5 years and 265 days ago.

Previous Next


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