Re: when options conflict

[Benno Schulenberg]

Paul Eggert wrote:
> Sometimes two options are incompatible.  In these cases, it is
> sometimes useful to have otherwise-incompatible options override
> each other.  But this should be limited.  It's normally better to 
> report an error to a user who specifies incompatible options, as
> such a user is requesting impossible behavior.

Both the pair -l/-L and -h/-H are each other's logical counterpart, 
having each override the other creates in my opinion no complexity, 
and implementing this override is simpler than detecting that the 
counterpart has already been used and then reporting an error.

Also, it is sometimes convenient to be able to override an option by 
tacking it onto a previous command, and not having to change it 
somewhere in the middle of the line.  For example:

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

If one now wants to see for a moment which files the results are 
coming from, one does:

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

It would be annoying if this would produce an error.

It's fine to leave this override of -h and -H, and -l and -L, 
undocumented, but the implementation is so simple, why not do that?  

> Grep has many options, and we should be wary about documenting or
> supporting complicated interactions among them.  Complexity like
> that generally causes more problems than it cures.

>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.  
GNU grep conforms to this.  Should the man and info page not 
document this behaviour?

Benno