bug-grep
[Top][All Lists]
Advanced

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

Re: when options conflict


From: Benno Schulenberg
Subject: Re: when options conflict
Date: Fri, 19 May 2006 19:14:07 +0200
User-agent: KMail/1.9.1

Charles Levert wrote last November:
> * On Friday 2005-11-11 at 22:09:17 +0100, Benno Schulenberg wrote:
> > Ideally, what should grep do when options conflict?
> >
> > 1) Abort with an error message.
> > 2) Give a warning and let an arbitrary option take precedence,
> >    depending on how things are implemented.
> > 3) Say nothing and always have the last of the conflicting
> > options determine the outcome.
>
> I personally would prefer a split approach:
>
>    -- Aborting in error for -G/-F/-E/-P,

Definitely.  Otherwise someone might think that something 
like 'grep -E -e extendedpattern -P -e perlpattern' would work.

>       -L/-l/-c/-q,

Maybe.  But according to a comment in grep.c: /* POSIX.2 says 
that -q overrides -l, which in turn overrides the other output 
options. */

The man page should document this behaviour, which is the current 
behaviour: -q overrules -l/-L, which both overrule -c, and all of 
them overrule the prefix stuff.

>       and -c/-m conflicts. 

These do not conflict.

>    -- Silent priority of -L/-l/-c/-q over
>       anything that is either prefix or line
>       content.
>
>    -- Silent override for multiple --color,
>       multiple -A/-B/-C,
>       multiple -a/--binary-files/-I,
>       multiple -D, multiple -d/-r.
>
>    -- Priority to -x for -w/-x.  This is already
>       their logical intersection.

Yes, but it would be simpler to also make it a silent override.  
Having several different mechanisms makes the baviour of grep's 
command line less transparent to the user.

>    -- -A/-C and -m is very tricky, given the
>       resume-search-on-stdin requirement.
>       Printing context lines up to but excluding
>       the next match would be nice, but it's
>       impossible to respect said requirement then.

I don't see a problem here: -m truncates stuff, also context lines 
if that so happens.

>    -- -A/-B/-C and -o but no -v with priority
>       to -o and a warning is probably ok.

Combination of -A/-B/-C and -o should in my opinion produce the 
context lines in full and for matching lines only the matching 
text.  If one really only wants the matching stuff, then one 
shouldn't specify any -A/-B/-C, or specify -C0.

>    -- -A/-B/-C and -v but no -o is probably
>       broken because it does not output a '--'
>       separator line.

It does here.  For example 'grep -A2 -v the *' in grep's main dir.

>    -- -A/-B/-C and -v and -o has probably been
>       broken by systematically setting
>       out_before=out_after=0 in main().  Oops.

Yep.  This ought to be fixed before attempting a release.

>       The whole thing with the warning should
>       be avoided then.  I don't like the warning
>       in any case after all, come to think of it.
>
>       Really, aren't -o and -A/-B/-C orthogonal
>       in command-line specification, but
>       justifiably interacting in execution?
>       Yep, that warning is bogus.

Cool.  I didn't like the warning either.  :)

>    -- Silently ignore
>       -b/-H/-h/--label/-n/-T/-u/-Z when there
>       is no per-line output (-L/-l/-c/-q).

That sounds fine.  It ought to be documented though.

> Reading back what I just wrote, I think much
> of it is already that way and just needs to
> be documented explicitly.

Precisely.  :)  I would make patches, but I haven't signed, and 
won't sign, a copyright assignment.

Benno




reply via email to

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