Benno Schulenberg <[EMAIL PROTECTED]> 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.
