Paul Eggert wrote: > Benno Schulenberg <[EMAIL PROTECTED]> 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
