[debbugs-tracker] bug#15127: closed (grep not taking last conflicting option as choice?)

[GNU bug Tracking System]

Your message dated Mon, 19 Aug 2013 07:55:36 -0600
with message-id <address@hidden>
and subject line Re: bug#15127: grep not taking last conflicting option as 
choice?
has caused the debbugs.gnu.org bug report #15127,
regarding grep not taking last conflicting option as choice?
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
15127: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15127
GNU Bug Tracking System
Contact address@hidden with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> grep not taking last conflicting option as choice?
>
>
>
>
> Date: 
>
> Sun, 18 Aug 2013 19:50:24 -0700
>
>
>
>
> User-agent: 
>
> Thunderbird
>
>
>
>
>
> Isn't it usually the case with conflicting options that the last
> one gets taken as the choice, with choices on the command line
> overriding choices in the environment?
>
> Grep doesn't seem to follow this convention.
>
> Is there a reason why grep doesn't or did it
> used to and now chooses to do nothing in the case of
> conflicting options?  (eg. -P v. -E)
>
> I think the earlier behavior, especially in respect
> to cmdline value overriding the environment is more
> useful otherwise lines built up both by successive passes
> in make files and with those who specify defaults in GREP_OPTIONS,
> but expect cmd-line usage to override ENV...
>
> (coreutils 8.21)
>
> (or is grep not part of coreutils these days...hmmm...)
>
>
>
>
> --- End Message ---

--- Begin Message --- Subject: Re: bug#15127: grep not taking last conflicting option as choice? Date: Mon, 19 Aug 2013 07:55:36 -0600 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8

tag 15127 notabug
thanks

On 08/18/2013 08:50 PM, Linda Walsh wrote:
> 
> Isn't it usually the case with conflicting options that the last
> one gets taken as the choice, with choices on the command line
> overriding choices in the environment?
> 
> Grep doesn't seem to follow this convention.
> 
> Is there a reason why grep doesn't or did it
> used to and now chooses to do nothing in the case of
> conflicting options?  (eg. -P v. -E)
> 
> I think the earlier behavior, especially in respect
> to cmdline value overriding the environment is more
> useful otherwise lines built up both by successive passes
> in make files and with those who specify defaults in GREP_OPTIONS,
> but expect cmd-line usage to override ENV...
> 
> (coreutils 8.21)
> 
> (or is grep not part of coreutils these days...hmmm...)

Grep is its own project (address@hidden, per 'grep --help' output).
As such, I'm closing this as not a coreutils bug.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature

--- End Message ---