Re: when options conflict

[Benno Schulenberg]

Paul Eggert wrote:
> Benno Schulenberg <address@hidden> writes:
> > From the text under STDOUT on
> > http://www.opengroup.org/onlinepubs/009695399/utilities/grep.html
> > I gather that -q overrules -l, -l overrules -c, and -c
> > overrules -n.
>
> No, that's incorrect.  A POSIX-conforming script cannot use
> "grep -q -l".  Nor can it use "grep -l -c".  This follows from
> the SYNOPSIS section of the spec you referred to.

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".  The very addition of 
that last phrase tells me that although the options are defined as 
mutually exclusive, they can be specified together, and if they 
are, -q is the boss (no matter what the order).

> My original objection was to the idea of having option order
> matter. The order of options should be irrelevant.

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"?  This seems to imply that all 
options override identical options that appear earlier on the 
command line.

For me -H and -h are really the same option: -H==h0, -h==h1; when 
specifying '-h0 -h1' the result is -h1, when specifying '-h1 -h0' 
the result is -h0.

Or should that phrase about default options being placed in front be 
scratched and instead say that command line options only override 
incompatible options when they are in GREP_OPTIONS, but when they 
are put together on the command line the result is undefined?

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"?  This comes from
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap12.html
guideline 11.  In my mind this says that for identical options, the 
last one counts.

> My more-general objection is to having lots of complicated
> interrelationships among options.  The -c/-n business is a
> interrelationship that I'd rather not have, but we're stuck with
> it because tradition and the standard requires it.

You would have preferred the standard to say "[-c| -l| -n| -q]"?

> But when we 
> are adding options of our own, we should strive to avoid these
> interrelationships, and we should not encourage users to depend
> on any interrelationships that we have inadvertently introduced.

Okay.  But do you then propose to let grep error out on any 
incompatible combination of options?

Benno