Paul Eggert wrote: > Benno Schulenberg <[EMAIL PROTECTED]> writes: > > [...] > > Also, -h and -H are not always 100% inverses.
?? When is that? > > But addition is commutative: "-e a -e b" equals "-e b -e a". > > Why then say that these options and arguments "should be > > interpreted in the order specified"? > > Because in some other Unix utilities, the order does matter. For > example, "sed -e 's/a/bb/' -e 's/b/aa/'". This sort of usage is > meant for options with option-arguments, where the arguments can > be "appended" semantically. Okay, but I don't see where it says that the phrase is only intended for appending-type stuff. Is it not also meant for simple repeated options like in "-C3 -C2 -C1"? The order of different options should not matter, but that says nothing about the order of identical options (with differing arguments). > >> -n doesn't > >> really conflict with the other options; -n simply has no > >> effect if any of the other options are specified. > > > > But but but... the same can be said of -c in relation to -l/-q > > No. For example, -c says "output counts only". Yes, but that is clearly incorrect. Further down in the STDOUT section it says ''if more than one file argument appears [...] the grep utility shall prefix each output line by: "%s:", <file>'' and ''[if] the -c option is in effect, the remainder of each output line shall contain: "%d\n", <count>''. So counts get output together with file names. 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". > -l says "output file names only". These options clearly conflict. Not when the description of the -c option were phrased correctly. > In contrast, -n says "output a line number before each matching > line that you output". This does not conflict with -c or -l: > e.g., "grep -c -n" never outputs any matching lines (because of > the -c), so the -n is irrelevant. Okay. > The relationship among options is way too complicated. It is. But we're not talking here about interrelations between -o and -n and -C and -c and -H, but just about simpler combinations. It all started with -w/-x. Okay, let the combination of -w and -x be its logical intersection -x. 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. This goes also for the logical pair -L/-l. 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 -- and makes grep's behaviour just slightly more uniform. > The complexity is not documented. And it > should not be documented, as that would be a disserverice to the > vast majority of users. Okay, let's not document the interrelations. Let's just tweak the functionality a bit. Benno
