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
