GNU bug report logs - #15127
grep not taking last conflicting option as choice?

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15127 in the body.
You can then email your comments to 15127 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: bug-coreutils <at> gnu.org
Subject: grep not taking last conflicting option as choice?
Date: Sun, 18 Aug 2013 19:50:24 -0700

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...)

Message #12 received at 15127-done <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Linda Walsh <coreutils <at> tlinx.org>
Cc: 15127-done <at> debbugs.gnu.org
Subject: Re: bug#15127: grep not taking last conflicting option as choice?
Date: Mon, 19 Aug 2013 07:55:36 -0600

[Message part 1 (text/plain, inline)]

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 (bug-grep <at> gnu.org, 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 (application/pgp-signature, attachment)]

Message #15 received at 15127-done <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: Eric Blake <eblake <at> redhat.com>
Cc: 15127-done <at> debbugs.gnu.org
Subject: Re: bug#15127: grep not taking last conflicting option as choice?
Date: Mon, 19 Aug 2013 10:59:02 -0700

Eric Blake wrote:
> 
> Grep is its own project (bug-grep <at> gnu.org, per 'grep --help' output).
> As such, I'm closing this as not a coreutils bug.
> 
---
I see...

Sorry about that..

It's hard to think of some things that are their own separate
projects as not being "coreutils" as they were a core part
of any unix system...  (that isn't meant to say anything about
where they "should" be located, just that the name of coreutils
tends to be a bit all encompassing of a few side projects...

Sigh.

Message #18 received at 15127 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: 15127 <at> debbugs.gnu.org
Subject: Re: bug#15127: grep not taking last conflicting option as choice?
Date: Mon, 19 Aug 2013 14:22:03 -0600

Eric Blake wrote:
> Grep is its own project (bug-grep <at> gnu.org, per 'grep --help' output).
> As such, I'm closing this as not a coreutils bug.

And worse grep isn't using this bug tracker.  If it were then we could
simply reassign the bug to the right package.  Bummer.

For people wondering what projects are served by this bug tracker here
is the top level page listing them.  Only eight projects at this time.

  http://debbugs.gnu.org/Packages.html

Bob

Message #21 received at 15127 <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 15127 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
 15157 <at> debbugs.gnu.org
Subject: Re: bug#15157: join doesn't follow norms and dies instead of doing
 something useful w/duplicate options
Date: Wed, 21 Aug 2013 21:54:49 -0700

Pádraig Brady wrote:
> On 08/21/2013 10:44 PM, Linda Walsh wrote:
>> Historically, options specified on the command line take precedence
>> over options in an init/rc-file or in the ENV.  Many utils
>> in a build process build up command lines in pieces -- with the
>> expectation that later values take precedence, allowing for
>> higher level make files to set defaults, while allowing make's
>> in sub directories to override options set in a parent.
>>
>> Defaulting to "fail", rather than proceed with latest input
>> data, is rarely useful for humans.  It's arguable whether or
>> not it is useful for machines in most cases.
>>
>> In the past, unix utils have tried to do what the user meant
>> rather than deliberately playing "stupid" and pretending to have
>> no clue about what was likely expected.
> 
> Right, to support subsequent specification of scripts etc.
> it's useful to allow options to be overridden.
> In addition this is how other systems behave wrt to
> input field separator options for example.
> 
> Now on the other hand, the ambiguity being diagnosed here
> in such an obtuse manner, is that one might think that _any_
> of the specified separators are supported in the input,
> rather than the last taking precedence.
----
	There are other utilities not all officially
under the official 'coreutils' project, but definitely
under the "core unix utilities" definition.  One of those
which started me looking at the inconsistencies was/is
grep(+flavors).

	There, you have the ENV var GREP_OPTIONS, which
I would argue should take the least precedence when compared
with the 'command name' and 'options on the command line'

	The "-[FEPG]" options are mutually exclusive and can
easily override each other w/o harm.

	To add spice, "egrep", uses the 'GREP_OPTIONS', but
isn't really compatible with 'grep' (as it is now) w/regards
to -- for example, the search-type switches.  I'm not sure
why, but egrep, right now, refuses all pattern options --this
is a real kicker:
egrep -E foo
egrep: egrep can only use the egrep pattern syntax
----
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.

There is no reason why "last specified" shouldn't apply there
as well (with the ENV being specified before the command was
entered, thus having lowest priority), the command name being
the 2nd thing typed, and having next priority, and options specified
to the command being the last thing typed, left to right.

It so happens that 'join' was used as a justification for
this behavior in 'grep', which was one of the reasons why I looked
at join (along with sort, and a few others) to note where there
might be inconsistencies and whether or not the trend of "fail"
taking precedence over deterministic and working behaviors that
have been defined as normal for as long as I can remember on *nix.


Do you see a reason why grep(+e/f) should fail -- or, especially,
why e/fgrep should fail due to conflicting options in a GREP env
var... or reject specification of a correct format?


> 
> New users of these tools may be caught out though.
---
	They wouldn't have any previous history to be caught
by.  When I came to *nix, I read the man page and noted that nearly
all of the utilities showed the same behavior (with the exception
of sort that might have it's options confused as applying to different
fields, not sure how likely that is).  I have come to rely on
option-override working in a number of utils -- with config files
taking the lowest priority (they are present before the user logs
in), followed by ENV vars (set each session), command name and
switches...(usually command name isn't part of that list, but
to make things consistent...)


> We could display a warning but that would negate most of
> the benefit of allowing overriding the option.
> I suppose we could support --debug on all utils to diagnose
> ambiguities like this, rather than disallowing them.
> I'll look at doing both of the above.
----
	--lint?

	debug has other connotations... or --anal^h^h^h^hstrict ?
;^)
> 
> thanks,
> Pádraig.
--
ditto.. and I need to know how to phrase the problem for the kernel
folks as they have quite a few places calling grep where they don't check
for status (let alone, now being affected by conflicting options)...

Could 15127 also be re-opened as it was closed unilaterally in the
presence of obvious bugs.  Thanks...

Message #24 received at 15127 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Linda Walsh <coreutils <at> tlinx.org>
Cc: 15127 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
 Pádraig Brady <P <at> draigBrady.com>, 15157 <at> debbugs.gnu.org
Subject: Re: bug#15127: bug#15157: join doesn't follow norms and dies instead
 of doing something useful w/duplicate options
Date: Thu, 22 Aug 2013 06:30:09 -0600

[Message part 1 (text/plain, inline)]

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.  An explicit
error is better than silently making a multitude of scripts misbehave.
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.

> Could 15127 also be re-opened as it was closed unilaterally in the
> presence of obvious bugs.  Thanks...

These are not obvious bugs.  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.

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

[signature.asc (application/pgp-signature, attachment)]

Message #27 received at 15127 <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: Eric Blake <eblake <at> redhat.com>
Cc: 15127 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>, Pádraig Brady <P <at> draigBrady.com>, 15157 <at> debbugs.gnu.org
Subject: Re: bug#15127: grep not taking last conflicting option as choice?
Date: Thu, 22 Aug 2013 15:18:30 -0700

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.

Message #30 received at 15127 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Linda Walsh <coreutils <at> tlinx.org>
Cc: 15127 <at> debbugs.gnu.org, 15157 <at> debbugs.gnu.org
Subject: Re: bug#15127: grep not taking last conflicting option as choice?
Date: Thu, 22 Aug 2013 16:27:57 -0700

On 08/22/13 15:18, Linda Walsh wrote:

>     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?

That doesn't describe what happened, and this sort of rhetoric
doesn't help to improve free software.  You might want to
try rephrasing that email in terms that are less inflammatory,
so that it's more likely to be read and acted on.  I stopped
reading after the above comment.

Message #33 received at 15127 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Linda Walsh <coreutils <at> tlinx.org>
Cc: 15127 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
 Pádraig Brady <P <at> draigBrady.com>, 15157 <at> debbugs.gnu.org
Subject: Re: bug#15127: grep not taking last conflicting option as choice?
Date: Thu, 22 Aug 2013 18:08:48 -0600

[Message part 1 (text/plain, inline)]

On 08/22/2013 04:18 PM, Linda Walsh wrote:
> 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.

And the point of free software is that YOU are free to modify the
software to fit your needs, and share your modifications; not to rant
that you got something at no price while demanding that someone else fix
it to meet your whims.  Share patches, rather than rants, and you will
gain a lot more friends in the world of free software.  If you are
unable to write patches, but the problem still affects your situation,
you could consider the possibility of hiring someone to write the patch
on your behalf and on your timeline, rather than waiting on the
generosity of others.  People are less motivated to fix bugs that you
report if you chew them out.

More than 50% of your mail was ranting about the behavior of grep, which
we already established is NOT part of the coreutils package.  If you
want to change the behavior of grep, please take your complaints (or
better yet, patches) over there, rather than wasting the time of a list
that has no control over grep's future.

>>> 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.

Since this is the bug tracker for coreutils, please demonstrate a simple
shell script (preferably that exists in a version control repository of
a public project, but not mandatory) where the behavior of an existing
coreutils' option handling causes an actual problem, and/or prove with
appropriate quotations that we are violating a constraint of a document
that we claim to conform to, rather than wasting time theorizing about
whether the corner-case option handling behavior is broken or done by
design.  A short demo speaks much louder than a multi-line prose.
Consistency may be nice, but when you carry on long discourses about
corner cases that no one uses in real life shell scripts, it's hard to
take you seriously.

Furthermore, just because we closed bug 15127 (grep) as not a bug in the
context of coreutils does not mean that we are unilaterally rejecting it
as a bug, rather that we don't need the paperwork to track something
that cannot be fixed in the context of coreutils.  So far, no one in
this thread has flat-out claimed that grep is not buggy (my own claim is
that it is not an obvious bug, but I did not rule out the possibility
that there might be a subtle bug, nor that behavior might be worth
changing - but champion that on the grep list, not here).  Nor has
anyone closed out 15157 (join) - as Pádraig mentioned, we are looking at
what could be done as an improvement in quality of implementation.

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

[signature.asc (application/pgp-signature, attachment)]

Message #36 received at 15127 <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: 15127 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Pádraig Brady <P <at> draigBrady.com>
Subject: bug#15127: grep not taking last conflicting option as choice?
Date: Thu, 22 Aug 2013 17:18:15 -0700

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.

Message #39 received at 15127 <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: Eric Blake <eblake <at> redhat.com>
Cc: 15127 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>, Pádraig Brady <P <at> draigBrady.com>, 15157 <at> debbugs.gnu.org
Subject: Re: bug#15127: grep not taking last conflicting option as choice?
Date: Thu, 22 Aug 2013 18:43:05 -0700

Eric Blake wrote:
> On 08/22/2013 04:18 PM, Linda Walsh wrote:
>> 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.
> 
> And the point of free software is that YOU are free to modify the
> software to fit your needs, and share your modifications;
----
Oh, so if I submit patches to fix the problems I've raised, they
will be incorporated?  Or is someone using their position of
source-code maintainer/gatekeeper to implement their own
vision while excluding others?

 not to rant
> that you got something at no price while demanding that someone else fix
> it to meet your whims.  Share patches, rather than rants, and you will
> gain a lot more friends in the world of free software. 
----
	I have shared multiple patches -- having them dropped on the floor
makes me unwilling to submit patches for things that they gatekeepers are
going to unilaterally reject anyway.


> 
> More than 50% of your mail was ranting about the behavior of grep, which
> we already established is NOT part of the coreutils package.
----
    Sorry, I thought the 15127 was the bug that got assigned when I
send the email to the bug-grep reported here:
http://lists.gnu.org/archive/html/bug-grep/2013-08/msg00017.html

and responded to here:
http://lists.gnu.org/archive/html/bug-grep/2013-08/msg00018.html

It doesn't seem that the grep bug was assigned a bug number, though it
appeared to be rejected and my response was in regards to it.

Message #42 received at 15127 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Linda Walsh <coreutils <at> tlinx.org>
Cc: 15127 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
 Pádraig Brady <P <at> draigBrady.com>
Subject: Re: bug#15127: grep not taking last conflicting option as choice?
Date: Thu, 22 Aug 2013 20:29:49 -0600

[Message part 1 (text/plain, inline)]

On 08/22/2013 06:18 PM, Linda Walsh wrote:

[a repeated message to bug-coreutils]

Observe:
http://debbugs.gnu.org/15127

In particular, note that your message 27 and 36 are practically
identical in content (with slight reformatting).
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15127#27
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15127#36

How many times do we have to tell you?  bug-grep <at> gnu.org does NOT use
debbugs; sending mail to bug 15127 (a bug in the coreutils tracker) does
NOT get read on the bug-grep list.  Your pleas to this list are falling
on deaf ears because our pleas to you to report it to the correct list
are being unheeded.

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

[signature.asc (application/pgp-signature, attachment)]

Message #45 received at 15127 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Linda Walsh <coreutils <at> tlinx.org>
Cc: 15127 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
 Pádraig Brady <P <at> draigBrady.com>, 15157 <at> debbugs.gnu.org
Subject: Re: bug#15127: grep not taking last conflicting option as choice?
Date: Thu, 22 Aug 2013 20:38:41 -0600

[Message part 1 (text/plain, inline)]

On 08/22/2013 07:43 PM, Linda Walsh wrote:
>> And the point of free software is that YOU are free to modify the
>> software to fit your needs, and share your modifications;
> ----
> Oh, so if I submit patches to fix the problems I've raised, they
> will be incorporated?

Yes, if your patches stand on their own technical merit, and you have
assigned copyright to the FSF for non-trivial patches, then they will be
taken.

>     I have shared multiple patches -- having them dropped on the floor
> makes me unwilling to submit patches for things that they gatekeepers are
> going to unilaterally reject anyway.

Of course, by taking that approach, none of your patches will be
reviewed.  Not all projects "unilaterally reject" patches, and on this
list, we try hard to give constructive comments as to whether a patch is
technically sound, where it could be improved, or at a minimum leave
feedback on why it might not be appropriate upstream but where you are
still free to use it in your own downstream build.

>     Sorry, I thought the 15127 was the bug that got assigned when I
> send the email to the bug-grep reported here:
> http://lists.gnu.org/archive/html/bug-grep/2013-08/msg00017.html

Not quite. 15127 is the coreutils bug that you opened here:
https://lists.gnu.org/archive/html/bug-coreutils/2013-08/msg00058.html

Bug-grep does not use the debbugs tracker, so there is no bug number,
other than the URL of the message archive that you just quoted.

> 
> and responded to here:
> http://lists.gnu.org/archive/html/bug-grep/2013-08/msg00018.html
> 
> It doesn't seem that the grep bug was assigned a bug number,

Correct - anything that doesn't use debbugs is not given a debbugs number.

> though it
> appeared to be rejected and my response was in regards to it.

If you want to know which package owns a debbugs number, visit that bug,
and note the header.  In particular,

http://debbugs.gnu.org/15127

starts with:

Package: coreutils;

meaning that it is still tied to coreutils, not grep.

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

[signature.asc (application/pgp-signature, attachment)]

Message #48 received at 15127 <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: Eric Blake <eblake <at> redhat.com>
Cc: 15127 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>, Pádraig Brady <P <at> draigBrady.com>
Subject: Re: bug#15127: grep not taking last conflicting option as choice?
Date: Thu, 22 Aug 2013 21:34:59 -0700

Eric Blake wrote:
> On 08/22/2013 06:18 PM, Linda Walsh wrote:
> 
> [a repeated message to bug-coreutils]
> 
> Observe:
> http://debbugs.gnu.org/15127
> 
> In particular, note that your message 27 and 36 are practically
> identical in content (with slight reformatting).
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15127#27
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15127#36
----
	Interesting that you take them as identical in content
when the 2nd was specifically reworded to remove verbiage that
some found offensive.

	I would point out to people that while some people
take offense to the verbiage used in the first one, the difference
in wording doesn't even show up as a blip on others' reading
of the two notes...

FWIW, Eric, the 2nd was rewritten by request.  I find it
unsurprising that you didn't notice the delta's.  (that's
an observation, not a veiled insult).

Message #51 received at 15127 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Linda Walsh <coreutils <at> tlinx.org>
Cc: 15127 <at> debbugs.gnu.org
Subject: Re: bug#15127: grep not taking last conflicting option as choice?
Date: Thu, 22 Aug 2013 21:42:10 -0700

Linda Walsh wrote:
> Interesting that you take them as identical in content
> when the 2nd was specifically reworded to remove verbiage that
> some found offensive.

I'm afraid that the revised email still contained
several ad hominem attacks.

Message #54 received at 15127 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Bob Proulx <bob <at> proulx.com>
Cc: 15127 <at> debbugs.gnu.org
Subject: Re: bug#15127: grep not taking last conflicting option as choice?
Date: Sat, 24 Aug 2013 11:53:13 -0700

Hi Bob,

I would really like to switch grep (and diffutils, gzip, etc.) to
bug.gnu.org tracker, but haven't had time recently.
If someone manages to do that, I would certainly appreciate it.

Jim

Message #57 received at 15127 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: 15127 <at> debbugs.gnu.org
Subject: Re: bug#15127: grep not taking last conflicting option as choice?
Date: Sat, 24 Aug 2013 13:09:27 -0600

Hi Jim,

Jim Meyering wrote:
> I would really like to switch grep (and diffutils, gzip, etc.) to
> bug.gnu.org tracker, but haven't had time recently.
> If someone manages to do that, I would certainly appreciate it.

I think Glenn Morris is the only person who can do this setup.  I
think a note over to help-debbugs <at> gnu.org asking for setup is the way
to get this going.  I don't know what his availability will be.  On
the mailing list side of things there isn't any change.  It is all
over on debbugs.gnu.org.

I will write a note over there and ask and get this process going for grep.

Bob

Message #60 received at 15127 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bob Proulx <bob <at> proulx.com>
Cc: 15127 <at> debbugs.gnu.org
Subject: Re: bug#15127: grep not taking last conflicting option as choice?
Date: Sat, 24 Aug 2013 17:43:49 -0700

Bob Proulx wrote:
> I will write a note over there and ask and get this process going for grep.

Perhaps it'd be simpler just to forward bug-grep etc. to
bug-coreutils?  That'd make the bug-handler side easier
to deal with.  There's little advantage to keeping all
the bug reports separate.

Message #63 received at 15127 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: 15127 <at> debbugs.gnu.org
Subject: Re: bug#15127: grep not taking last conflicting option as choice?
Date: Sun, 25 Aug 2013 12:29:01 -0600

Paul Eggert wrote:
> Perhaps it'd be simpler just to forward bug-grep etc. to
> bug-coreutils?  That'd make the bug-handler side easier
> to deal with.  There's little advantage to keeping all
> the bug reports separate.

It doesn't scale.  Would all GNU bugs to go the coreutils tracker and
mailing list?  That would quickly become very busy here.  It is hard
enough to keep the coreutils project manageable.  It would be the same
if we were to take all of the separate project mailing lists and
combine them all together into one.

Under the hood it is all one BTS.  The difference is only to which
project name the reports get associated with for the project bugs
summary page.  And on the GNU side which mailing list to CC when the
reports come through.  When a new project is added it doesn't set up a
separate BTS.  It is just a new project mailing list association so
that reports tagged to that project can be sent to the right mailing
list.

I think it would be better if we expanded the use to other projects
such as grep.  Then we could simply reassign the bugs to the correct
project and all of the history trail before it would be preserved.

Bob

Message #66 received at 15127 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bob Proulx <bob <at> proulx.com>
Cc: 15127 <at> debbugs.gnu.org
Subject: Re: bug#15127: grep not taking last conflicting option as choice?
Date: Sun, 25 Aug 2013 11:40:40 -0700

Bob Proulx wrote:
> It doesn't scale.

That'd be true if we talked about every GNU project,
but I was thinking of just adding grep, gzip, and diffutils.
They don't get much email.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.