Benno Schulenberg <[EMAIL PROTECTED]> writes: >> Also, -h and -H are not always 100% inverses. > > ?? When is that?
When they are no-ops. For example, -h is a no-op in the command "grep -h foo". (This is yet another complexity of the grep option syntax.) > I don't see where it says that the phrase is only intended > for appending-type stuff. That part of the Posix utility syntax guidelines is meant not only for appending-type stuff. Howver, it is intended only for a repeated option with option-arguments. We should not attempt to use that wording as a means to wiggle out of the general principle that the order of different options should not matter. > Instead of "Write only a count of selected lines" the -c option > should say "Instead of the selected lines, write per file only a > count of these lines". That change would be fine, but it doesn't affect the conclusion. >> -l says "output file names only". These options clearly conflict. > > Not when the description of the -c option were phrased correctly. More would have to be changed. The description under STDOUT currently doesn't make sense if -l and -c are both specified. (This is not a bug in the standard, since the SYNOPSIS makes it clear that they cannot both be specified.) > It all started with -w/-x. Okay, let the combination of -w and -x > be its logical intersection -x. That's fine, if it's logical, since order does not matter. > But for all repeated options, > like -C or --color or -D or -d or -m, in the current implementation > the last value given is the one that counts. That doesn't sound right to me. For example, if -m NUM means "output no more than NUM lines", then multiple instances of -m should accumulate by taking the minimum, and "-m 50 -m 100" should be equivalent to "-m 50". Under this interpretation, order wouldn't matter, which is a good thing. > This goes also for the logical pair -L/-l. That also doesn't make sense to me. If -L means the opposite of -l, then a user who specifies both is confused, and should be warned about the problem. On the other hand, if -L means "output the names of files that don't match", and -l means "output the names of files that do match", then "grep -l -L" and "grep -L -l" should both output the names of all input files. Either way, the option order should not matter. > Why not make the logical pair -H/-h behave > the same way? It robs the user of no functionality, it just gives > him or her a tiny bit extra It robs the user by adding unnecessary complexity to the system. This is an extra overhead for the user. It's a bit like saying, for the C language, "why not interpret A+B to mean 'max(A,B)' when A is less than B"? This robs the user of no functionality, since a user who wants addition when A<B can simply write "B+A". And it gives the user a tiny bit extra, since they now have a max operator which C otherwise does not have. Of course I am not seriously suggesting this; it's just an example of why it is not always a good idea to discard commutativity and associativity in the pursuit of some minor extra feature.
