[Top][All Lists]
[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
- Re: when options conflict,
Benno Schulenberg <=
- Re: when options conflict, Paul Eggert, 2006/05/19
- Re: when options conflict, Tony Abou-Assaleh, 2006/05/20
- Re: when options conflict, Benno Schulenberg, 2006/05/20
- Re: when options conflict, Paul Eggert, 2006/05/20
- Re: when options conflict, Benno Schulenberg, 2006/05/21
- Re: when options conflict, Paul Eggert, 2006/05/22
- Re: when options conflict, Benno Schulenberg, 2006/05/22
- Re: when options conflict, Paul Eggert, 2006/05/22
- Re: when options conflict, Benno Schulenberg, 2006/05/22
- Re: when options conflict, Paul Eggert, 2006/05/23