Re: when options conflict

[Paul Eggert]

Benno Schulenberg <address@hidden> 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.