bug#15157: 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.
---
        "Anyone" making broad statements that apply to all of humanity
about their own systems is hardly someone who should be commenting
on 'dumb'.

        Why is it that some people use their positions to modify
widely used source as a chance to implement power-over and domination
over other people?   Isn't the point of software to give users the freedom
to make their choices -- to help them do their job?  It's not to enforce
a particular mind-think or dogma.

>   An explicit
> error is better than silently making a multitude of scripts misbehave.
----
        They won't misbehave -- they will fail if the expressions are
not compatible.  There are few cases where someone deliberately needs
"|" in an expression or "+" in a regex, to NOT have it's normal meaning.
That doesn't mean they don't exist, but it is rare.

        Furthermore, if someone wants a particular *engine* for matching
what I said was the point -- the engine on the command line would take
precedence over any in the environment.

        Also, for egrep/fgrep -- they are reading "GREP"'s options.
If they don't understand the option/can't use it (-F/-E/-P), then
they should ignore options they don't understand, as they are not
reading their own options but those of 'grep' which DOES understand
those options.

        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 just to enforce your
narrow minded view of how others should use their own systems is the
height of arrogance.


> 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.
---
        I think all should pay attention to a .greprc/.fgreprc/.egreprc --
would be more easily tailored and not have the env issues you mention --
BUT it is STILL the case that command line options would override previously
set options in a config file.

> > 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 still 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.
===
        Implementing things down to the worst behaviors allowed
by POSIX is worse than adhering to new posix rules that dumb down
behaviors of utilities to protect 5-year old children.  That it
meets the standard of the "lowest-common denominator standard, is
hardly worth bragging about, let alone using a justification for
inconsistent and flakey design.