bug-grep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: when options conflict


From: Paul Eggert
Subject: Re: when options conflict
Date: Mon, 22 May 2006 11:50:58 -0700
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

Benno Schulenberg <address@hidden> writes:

> They are different, but not in the same sense as for instance -C 
> and -n and -o are different.  -H and -h are tightly bound together: 
> they don't just specify conflicting behaviour, they specify each 
> other's inverse behaviour, which for me makes them the two sides of 
> a single coin.

Perhaps for you that's true; but almost everybody else would say that
two options conflict if they specify contradictory behavior.

Also, -h and -H are not always 100% inverses.  And this increases the
complexity of explaining what they do.


>> That is talking about a different situation, namely, options like
>> -e that are allowed to be repeated.
>
> 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.  It is not meant for otherwise-conflicting
options.


>> > You would have preferred the standard to say "[-c| -l| -n|
>> > -q]"?
>>
>> Yes, mildly, as it makes little sense to combine -n with the
>> other options.  However, it's not a big deal, since -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".  -l says "output file
names only".  These options clearly conflict.

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.


> In my opinion grep is now doing precisely the right thing: make no 
> fuss when it is clear what the end result should be.

It is not clear at all.  The relationship among options is way too
complicated.  The complexity is not documented.  And it should not be
documented, as that would be a disserverice to the vast majority of
users.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]