[Top][All Lists]

[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: Sun, 21 May 2006 23:33:19 -0700
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

Benno Schulenberg <address@hidden> writes:

> Yes, with "[-c| -l| -q]" in the synopsis it seems to say that these 
> options are mutually exclusive.  But if that really is the case, 
> then after saying "If the -l option is in effect" there really is 
> no need to add "and the -q option is not".

True.  I just now filed an interpretation request on this.  See

>> My original objection was to the idea of having option order
>> matter. The order of options should be irrelevant.
> What to do then with the text in the man page under GREP_OPTIONS 
> saying "This variable specifies default options to be placed in 
> front of any explicit options"?

It would be better just to say that GREP_OPTIONS specifies default
options.  Putting in the bit about order is over-specification, and is
part of this confusion.  One shouldn't think, for example, that it's
OK to put incompatible options into GREP_OPTIONS.

> For me -H and -h are really the same option

That doesn't match my intuition at all.  I think they're completely
contradictory options.  -H says to print the file name, and -h says to
not print the file name.  Every ordinary user would say that these are
two different options, and that they specify conflicting behaviors.

> Or should that phrase about default options being placed in front be 
> scratched and instead say that command line options only override 
> incompatible options when they are in GREP_OPTIONS, but when they 
> are put together on the command line the result is undefined?

Yes, that would make sense.

> What about "If an option that has option-arguments is repeated, 
> the option and option-argument combinations should be interpreted 
> in the order specified on the command line"?  This comes from
> http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap12.html

That is talking about a different situation, namely, options like -e
that are allowed to be repeated.  You can say "grep -e a -e b", and
this is OK.  However, the repetition is ordinarily intended to provide
additional information via new option-arguments.  It's not intended to
override previously specified (and incompatible) 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.

> do you then propose to let grep error out on any 
> incompatible combination of options?

This would make the most sense, yes.

reply via email to

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