[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
<http://www.opengroup.org/sophocles/show_mail.tpl?CALLER=index.tpl&source=L&listname=austin-review-l&id=2063>.
>> 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.
- Re: when options conflict, Benno Schulenberg, 2006/05/19
- Re: when options conflict, Paul Eggert, 2006/05/19
- Re: when options conflict, Tony Abou-Assaleh, 2006/05/20
- Re: when options conflict, Benno Schulenberg, 2006/05/20
- Re: when options conflict, Paul Eggert, 2006/05/20
- Re: when options conflict, Benno Schulenberg, 2006/05/21
- Re: when options conflict,
Paul Eggert <=
- Re: when options conflict, Benno Schulenberg, 2006/05/22
- Re: when options conflict, Paul Eggert, 2006/05/22
- Re: when options conflict, Benno Schulenberg, 2006/05/22
- Re: when options conflict, Paul Eggert, 2006/05/23
- Re: when options conflict, Benno Schulenberg, 2006/05/23
- Re: when options conflict, Julian Foad, 2006/05/25
- Re: when options conflict, Tony Abou-Assaleh, 2006/05/26
- Re: when options conflict, Tony Abou-Assaleh, 2006/05/22
- Re: when options conflict, Paul Eggert, 2006/05/23
- Re: when options conflict, Tony Abou-Assaleh, 2006/05/23