Re: when options conflict

[Paul Eggert]

Benno Schulenberg <address@hidden> writes:

> implementing this override is simpler than detecting that the 
> counterpart has already been used and then reporting an error.

The main goal is simplicity of use, not of implementation.  Here, the
difference in implementation is trivial, so the only question that
really matters is which behavior is easier to specify and to remember.

> Also, it is sometimes convenient to be able to override an option by 
> tacking it onto a previous command

Yes, that's the main argument for overriding.  But it is a dangerous
one, since it inevitably leads to having the order of options matter,
and that increases complexity of use.  Occasionally the extra
complexity is worth it, but usually not.  This is why the POSIX
utility syntax guidelines generally recommend against having option
order matter.

>   grep -m5 -h -n -s -T where * -H

I see the point of that example, but it's not as strong an argument as
what I'd like to see.  The example is complicated, and tricky, and
99.9% of grep users won't even understand it.  Anybody who's expert
enough to be using grep like that, won't be fazed by our sticking to
simple rules where option order does not matter.

> 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.  You are correct only
for -c and -n.

> Should the man and info page not document this behaviour?

Yes it should, for -c and -n.  But order does matter here.
-c overrides -n regardless of whether one uses "grep -c -n" or
"grep -n -c".

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

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.  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.

Traditional/POSIX grep can get away with bending the rules a bit
because it has so few options (only 12) and so few option interactions
(only the one you mentioned, plus one other involving -e and -f).  But
even POSIX grep has problems with weird option interactions that few
grep users know about.  GNU grep has about 4 times as many options,
which means it has about 16 times as many potential interactions.  So
the problem will be more than an order of magnitude worse with GNU
grep, unless we control it by keeping our options independent of each
other whenever possible.