Re: when options conflict

[Charles Levert]

* On Saturday 2005-11-12 at 23:44:02 -0800, Paul Eggert wrote:
> Charles Levert <address@hidden> writes:
> 
> > What do other grep implementations do (for
> > those that support extended options that lend
> > themselves to feature interaction problems)?
> 
> I just checked Solaris 10 /usr/xpg4/bin/grep, and
> it reports an error if you specify both -E and -F.

So let's keep this as is for grep,
which is just like that already.

The new GNU egrep and fgrep will also report
an error for this, but it will be that they
don't know any -E or -F option.  Just like the
traditional programs that solely justify their
continued existence for historical applications.


> Personally I prefer the POSIX guidelines: that is, the order of
> options should not matter.  Often this can be done by interpreting the
> meanings of options appropriately.  For example, with diffutils if you
> specify
> 
> diff -c -C 4
> 
> then this is equivalent to
> 
> diff -C 3 -C 4
> 
> which in turn is equivalent to diff -C 4, since if you ask for N lines
> of context and then ask for M lines of context, diff takes the
> greater.  Hence the order of options is not material.

I like both the ideas of max() and having several
GNU programs with similar options behave in a
consistent way.  I vote for this in grep.

sum() would also have the commutative property,
but it would take some users by surprise!