bug-grep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#31537: Combining -v and -A/-B/-C options


From: Garreau\, Alexandre
Subject: bug#31537: Combining -v and -A/-B/-C options
Date: Mon, 21 May 2018 08:42:42 +0200
User-agent: Gnus (5.13), GNU Emacs 25.1.1 (x86_64-pc-linux-gnu)

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 search programming ant | grep -v '^lib' -A 2 | less
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:
[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
>> 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>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]