Re: when options conflict

[Charles Levert]

* On Monday 2005-11-14 at 00:50:25 +0100, Benno Schulenberg wrote:
> Charles Levert wrote:
> > * 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.
> 
> [Skipping the details for now.]
> 
> >          8. ...
> >             The use of conflicting
> >             mutually-exclusive arguments produces
> >             undefined results, 
> 
> Okay, so this allows for the current situation, solution 2).
> 
> >         11. The order of different options
> >             relative to one another should
> >             not matter,
> 
> This disallows solution 3), which I preferred, but which would be 
> complicated anyway.

 From a compliance point-of-view, I guess things
that come from configuration files (which
grep doesn't have, yay!) and from environment
variables (GREP_OPTIONS) could be excused from
this and given lesser priority, even if they
are formatted just like command-line options.

But, indeed, complicated is the key word and I
don't care much for it for this reason.


> Well, then I would prefer solution 1), always 
> abort if two options cannot both be satisfied: better have no 
> output at all instead of output that is different from what one 
> thought, not notice it (grep being used in a pipe), and interpret 
> the result wrong.
> 
> >                         unless the options are 
> >             documented as mutually-exclusive
> >             and such an option is documented to
> >             override any incompatible options
> >             preceding it.
> 
> This will need to be documented then at least for the -d and -r 
> combinations.
> 
> >             If an option that 
> >             has option-arguments is repeated,
> >             the option and option-argument
> >             combinations should be interpreted
> >             in the order specified on the
> >             command line.
> 
> This I understand to mean that "-C2 -C5" means "-C5", and "-C5 -C2" 
> means "-C2",

This is the combination of "in the order
specified on the command line" and tail(),
or whatever the mathematical term for this is.


> because if max() was used here, then the order wouldn't 
> matter.

But this wouldn't contradict "in the order
specified on the command line" either, if we
explain the max() thing.


> GNU grep behaves this way (last one counts),

Yes.


> but GNU diff 
> simply aborts: "diff: conflicting output style options".

Mine doesn't.

I have both

   diff (GNU diffutils) 2.8.1
   diff (GNU diffutils) 2.8.7

For GNU diff, -C and -U do conflict.  Are you
sure you don't have a -u on that command line
somewhere and expect -C to be usable with it?
If so, -u (short for -U3) only combines with -U,
and -c (short for -C3) only combines with -C.

The -p used to have weird interactions, iirc.
I think "diff -up" was just like "diff -cp" =
"diff -p" at some point.  Which is why I got
used to "diff -pu", again iirc.  But this is no
longer a problem now:  "diff -up" = "diff -pu".