Re: when options conflict

[Benno Schulenberg]

Paul Eggert wrote:
> Benno Schulenberg <address@hidden> writes:
> > Yes, with "[-c| -l| -q]" in the synopsis it seems to say that
> > these options are mutually exclusive.  But if that really is
> > the case, then after saying "If the -l option is in effect"
> > there really is no need to add "and the -q option is not".
>
> True.  I just now filed an interpretation request on this.

Okay.  Let's wait and see.  :)

> > What to do then with the text in the man page under
> > GREP_OPTIONS saying "This variable specifies default options to
> > be placed in front of any explicit options"?
>
> It would be better just to say that GREP_OPTIONS specifies
> default options.  Putting in the bit about order is
> over-specification, and is part of this confusion.

Agreed, on all points.

> > For me -H and -h are really the same option
>
> That doesn't match my intuition at all.  I think they're
> completely contradictory options.  -H says to print the file
> name, and -h says to not print the file name.  Every ordinary
> user would say that these are two different options, and that
> they specify conflicting behaviors.

They are different, but not in the same sense as for instance -C 
and -n and -o are different.  -H and -h are tightly bound together: 
they don't just specify conflicting behaviour, they specify each 
other's inverse behaviour, which for me makes them the two sides of 
a single coin.

> > What about "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"?
>
> That is talking about a different situation, namely, options like
> -e that are allowed to be repeated.  You can say "grep -e a -e
> b", and this is OK.  However, the repetition is ordinarily
> intended to provide additional information via new
> option-arguments.

But addition is commutative: "-e a -e b" equals "-e b -e a".  Why 
then say that these options and arguments "should be interpreted in 
the order specified"?  To me that only makes sense when later 
specifications override earlier ones.

(It would also make sense in a few other cases: if an option would 
specify a bitshift, or when an option's arguments get concatenated; 
also then order would matter.  But I don't know any such options.)

> > You would have preferred the standard to say "[-c| -l| -n|
> > -q]"?
>
> Yes, mildly, as it makes little sense to combine -n with the
> other options.  However, it's not a big deal, since -n doesn't
> really conflict with the other options; -n simply has no effect
> if any of the other options are specified.

But but but... the same can be said of -c in relation to -l/-q, and 
of -l in relation to -q.  So you should either say an emphatic yes 
to "[-c|-l|-n|-q] [-isvx]", or be fine with "[-cilnqsvx]" too.

> > do you then propose to let grep error out on any
> > incompatible combination of options?
>
> This would make the most sense, yes.

You would wish 
  grep -C2 -dskip -hi where * -C4
  grep -C2 -dskip -hi where * -H
  grep -C2 -dskip -hi where * -l
  grep -C2 -dskip -hi where * -r
all to error out?  The horror!

In my opinion grep is now doing precisely the right thing: make no 
fuss when it is clear what the end result should be.  The only 
thing that needs modification is that it should error out on any 
combination of -c/-l/-q when POSIXLY_CORRECT is set.

Benno