Re: when options conflict

[Benno Schulenberg]

Paul Eggert wrote:
> Benno Schulenberg <address@hidden> 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