Paul Eggert wrote: > 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.
Cool. Now... the thing says that "the option and option-argument combinations should be interpreted in the order specified". As argued before, this means to me that _order matters_ for repeated options. For min() and max() functions order is irrelevant, so these cannot be the intended ways of interpreting repeated options. When arguments are simple numbers, how can order matter? Only when either the first one or the last one counts. The last one counting is more useful. > 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. Fine. For different options. But not for repeated occurrences of the same option with different arguments. > > 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. Sure it does. The general case for grep is to search multiple files. Now imagine a confused user specifying both -l and -c on the command line. What should grep do? What is the logical intersection of 'only filenames' and 'filenames plus counts'? To me that is clear: 'filenames'. So -l blots out -c in the case of multiple files; for the corner case of a single file, the most logical thing to do is to have -l blot out -c too. > >> -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. Yes, the description of the -l option could be improved too. > The description under STDOUT > currently doesn't make sense if -l and -c are both specified. It makes perfect sense to me. It says: "If the -l option is in effect [...] Otherwise [...] The remainder [...]". This 'remainder' part refers only to the 'Otherwise' part, not to 'the -l option'. So when -l is in effect, -c is never even considered. > > 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. No, it's the wrong thing. When I say "yes... no... eh, yes", which one do I mean; when I say "50... 100... 80", which one do I mean? It's the last thing I mentioned what counts. But fine. Let's assume that min() is what governs -m. What about -C? Should also there the smallest number count, being the logical intersection? Fine. What about --color? Of never, auto, always; which is the smallest? -d, read, skip or recurse? -D, read or skip? No! Being able to override an option-argument with a new argument is _so_ convenient, and it is what grep now does in almost every case, surely that is not by accident? > > 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. I give up. Benno
