Re: when options conflict

[Benno Schulenberg]

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