Re: when options conflict

[Charles Levert]

* On Friday 2005-11-11 at 22:09:17 +0100, Benno Schulenberg wrote:
> When grep is given the options -l and -o together, or -l and -h, 
> for example, then the -l option appears to take precedence and the 
> other one is ignored; no warning is given.

This is an issue.  Ideally, it should be explored
fully at some point and we shouldn't forget about
it the mean time.  For this reason, I think this
is something to put in the Savannah bug tracker,
so that the red item keeps reminding us of it.

(After having written the stuff below, I now
realize there may be several individual bugs to
register there.)


> However, when combining -dskip and -r, then the last mentioned 
> option determines the outcome.  (This is useful, because when 
> someone has defined GREP_OPTIONS as "-Dskip -dskip", then it is 
> nice to be able to overrule this with -r on the command line.)
> 
> Ideally, what should grep do when options conflict?
> 
> 1) Abort with an error message.
> 2) Give a warning and let an arbitrary option take precedence,
>    depending on how things are implemented.
> 3) Say nothing and always have the last of the conflicting options
>    determine the outcome.

What do other grep implementations do (for
those that support extended options that lend
themselves to feature interaction problems)?

At this moment, this is dictated by
implementation details, such as many options
sharing a single variable or not.


> My preference will be clear.

Can we assume it's #3?
Or, did you mean that whichever approach is
chosen should be made more clear?


I personally would prefer a split approach:

   -- Aborting in error for -G/-F/-E/-P,
      -L/-l/-c/-q, and -c/-m conflicts.

   -- Silent priority of -L/-l/-c/-q over
      anything that is either prefix or line
      content.

   -- Silent override for multiple --color,
      multiple -A/-B/-C,
      multiple -a/--binary-files/-I,
      multiple -D, multiple -d/-r.

   -- Priority to -x for -w/-x.  This is already
      their logical intersection.  Turning off
      match_word in main() will then just avoid
      needless costly internal matcher logic.
      In practice, it may already behave that way,
      except for Pcompile().  No warning needed.

   -- -A/-C and -m is very tricky, given the
      resume-search-on-stdin requirement.
      Printing context lines up to but excluding
      the next match would be nice, but it's
      impossible to respect said requirement then.
      Maybe the current behavior is ok and it is
      the failing tests that need to be reworked.
      A warning and out_after=0 in main() would be
      nice.  Note that there is no conflict with
      -B (and thus half the interpretation of -C).

      The whole -m resume-search-on-stdin
      requirement currently broken with pipes
      by input buffering anyway.  Should this
      be warned against at execution time?
      Reverting to then using a bunch of
      read(fd, &buf, 1)s and per-line grepbuf()s
      wouldn't be too efficient.

   -- -A/-B/-C and -o but no -v with priority
      to -o and a warning is probably ok.
      Yes there are context lines, they just
      don't have any matches in them, so there
      really is no _true_ conflict here.

   -- -A/-B/-C and -v but no -o is probably
      broken because it does not output a '--'
      separator line.

   -- -A/-B/-C and -v and -o has probably been
      broken by systematically setting
      out_before=out_after=0 in main().  Oops.
      The whole thing with the warning should
      be avoided then.  I don't like the warning
      in any case after all, come to think of it.

      Really, aren't -o and -A/-B/-C orthogonal
      in command-line specification, but
      justifiably interacting in execution?
      Yep, that warning is bogus.

   -- Silently ignore
      -b/-H/-h/--label/-n/-T/-u/-Z when there
      is no per-line output (-L/-l/-c/-q).

(Any other conflicts?  Any misinterpretation?)

The rationale in error-vs-else is that some
stuff is normal to put in GREP_OPTIONS or in
a general shell alias (such as --color=auto),
and some isn't.

Reading back what I just wrote, I think much
of it is already that way and just needs to
be documented explicitly.  Doing things early
in main(), or wherever options are initially
processed, also qualifies as better
(code-behavior) documentation.


> But maybe there is a general POSIX or 
> GNU rule on what to do when options clash?

For GNU, I don't see anything in the "GNU Coding
Standards" or in getopt(3) that pertains to
exactly this.

For POSIX, see

   Base Definitions volume (XBD)
   12. Utility Conventions
   <http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap12.html>

      12.1 Utility Argument Syntax
         3. Options are usually listed in
            alphabetical order unless this would
            make the utility description more
            confusing.  There are no implied
            relationships between the options
            based upon the order in which they
            appear, unless otherwise stated
            in the OPTIONS section, or unless
            the exception in Guideline 11 of
            Utility Syntax Guidelines applies.
            If an option that does not have
            option-arguments is repeated,
            the results are undefined, unless
            otherwise stated.
         8. ...
            The use of conflicting
            mutually-exclusive arguments produces
            undefined results, unless a utility
            description specifies otherwise.
            ...

      12.2 Utility Syntax Guidelines
        11. The order of different options
            relative to one another should
            not matter, unless the options are
            documented as mutually-exclusive
            and such an option is documented to
            override any incompatible options
            preceding it.  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.

That doesn't help much in deciding.


(Wow.  179 lines!)