bug#15127: grep not taking last conflicting option as choice?

[Linda Walsh]

Eric Blake wrote:

> On 08/21/2013 10:54 PM, Linda Walsh wrote:
>
> > Ok, thank you for "sharing", but doesn't '-E' mean egrep pattern syntax?
> > That even, '-E' fails, telling the user that they can only
> > use the syntax they are specifying seems "abusive".  That
> > other options in grep DO take the 'last' option, but the
> > syntax options are disallowed, is inconsistent, unuseful and
> > creates breakages in existing scripts that don't know they
> > should clear GREP_OPTIONS in order for egrep and fgrep to
> > function correctly.
>
> Anyone that sets -E via GREP_OPTIONS is already breaking their own
> system, and we have no sympathy for their dumb action.
---
        (1) "Anyone" making broad statements that apply to all of humanity
about their own systems is hardly someone who should be commenting
on 'dumb'.

        (2) in the above example there was no "-E" in the user's
GREP_OPTIONS.   The conflict came in using "egrep -E" -- a user specifically
asking for extended grep syntax from the egrep command.  

	(3) As to your opinion on the proper use of GREP_OPTIONS: 
anything you say is suspect, since you feel that GREP_OPTIONS shouldn't
have been implemented as an ENV var to begin with.  

	It seems odd that you would bother to complain about how 
GREP_OPTIONS is used, when you feel that it shouldn't be present in
the first place.   I can't say that your opinion would be representative
of someone who isn't "pre-biased" the ENV option.


>   An explicit
> error is better than silently making a multitude of scripts misbehave.
----
        You are hand waiving using made up statistics.  Most scripts
won't misbehave and it is a minority of scripts that use 
features like "|" or "+" in RE's that don't want their extended
meanings.  The desire for expressive syntax in grep lead to the
addition of the even-more-complete Perl-regex.  If the demand was
not there for the more expressive syntax, that wouldn't have happened.


If someone wants a particular *RE-engine* for matching -- then 
either the specialized names (fgrep/egrep) would override ENV
options, and those would be over-ridden by explicit specification
on the command line (regardless of cmd-name).

The current behavior is already problematic in that 'egrep/fgrep'
are reading **"GREP"**'s options.  If they don't understand a
grep option or cannot use it (any syntax specification causes
a problem with egrep/fgrep), then they should ignore those 
options that are grep-specific.

        It was also my suggestion that *if* the user explicitly specified
an option on the command line -- then it should use the option on the
command line no matter if the program is grep/fgrep or egrep.

        A "grep" by any other name still knows how to use alternate
engines.  A deliberate crippling of utilities to enforce "the one,
right, true way" that you believe is the only acceptable use, 
seems to be undesirable demonstration of power.


> In my opinion, GREP_OPTIONS is a mistake - it's ONLY useful and safe
> purpose is to do automatic coloring when used from a terminal, but that
> can be done with an alias or shell function, and could have been done
> with an explicitly-named GREP_COLOR instead of GREP_OPTIONS - if only we
> could go back 20+ years and design it that way to begin with.
---
	Personally, I think all should pay attention to a 
.greprc/.fgreprc/.egreprc.  They would would be more easily tailored 
and not have the env issues you mention, but even in that case I would
still have command line options override previously set options in a config.

> > Could 15127 also be re-opened as it was closed unilaterally in the
> > presence of obvious bugs.  Thanks...
>
> These are not obvious bugs. 
---
        Inconsistent treatment of options is confusing to users and
causes errors.  On one hand you have grep paying attention to the
last option specified, like most other utilities have for 20+ years,
and on the other hand, you have some new options, that are inconsistent
with previously implemented options.   To have them operate on their
switches half and half is a design flaw--- a bug.


> As POSIX permits both behaviors (mutually
> exclusive options giving an error, vs. last option wins), it is merely a
> quality of implementation question, which crosses the line into
> subjective rather than objective.
===
        To use POSIX as a justification for bad or user-unfriendly
design is hardly a glowing recommendation.