GNU logs - #15157, boring messages

Message sent to bug-coreutils@HIDDEN:

Subject: bug#15157: join doesn't follow norms and dies instead of doing something useful w/duplicate options
Resent-From: Linda Walsh <coreutils@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Wed, 21 Aug 2013 21:46:02 +0000
Resent-Message-ID: <handler.15157.B.137712153028039 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 15157 <at> debbugs.gnu.org
Message-ID: <521534DA.5040302@HIDDEN>
Date: Wed, 21 Aug 2013 14:44:58 -0700
From: Linda Walsh <coreutils@HIDDEN>
User-Agent: Thunderbird
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

join is inconsistent with other utils (like cut, for example) in how
it handles a specification of a switch value that has already been
set.

1) if a switch is set more than once with the same value, it
doesn't complain, but if the options differ, unlike utilities
like 'cut', the tool dies rather than taking the final
specification as what is meant.

ex:
    cut -d'<TAB>' -d: -f1 </etc/passwd
doesn't issue any errors.

But the same thing with join:
join -t'<TAB>' -t: -f1 /etc/passwd /etc/group
join: incompatible tabs

???  tabs?  they are field separators.

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.

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.503 (Entity 5.503)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Linda Walsh <coreutils@HIDDEN>
Subject: bug#15157: Acknowledgement (join doesn't follow norms and dies
 instead of doing something useful w/duplicate options)
Message-ID: <handler.15157.B.137712153028039.ack <at> debbugs.gnu.org>
References: <521534DA.5040302@HIDDEN>
X-Gnu-PR-Message: ack 15157
X-Gnu-PR-Package: coreutils
Reply-To: 15157 <at> debbugs.gnu.org
Date: Wed, 21 Aug 2013 21:46:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-coreutils@HIDDEN

If you wish to submit further information on this problem, please
send it to 15157 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
15157: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D15157
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-coreutils@HIDDEN:

Subject: bug#15157: bug#15158: sort complains about incompatible options (that aren't) AND when it shouldn't
Resent-From: Paul Eggert <eggert@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Thu, 22 Aug 2013 00:08:02 +0000
Resent-Message-ID: <handler.15157.B15157.13771300758802 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Linda Walsh <coreutils@HIDDEN>
Cc: 15158 <at> debbugs.gnu.org, 15157 <at> debbugs.gnu.org
Message-ID: <52155655.9020001@HIDDEN>
Date: Wed, 21 Aug 2013 17:07:49 -0700
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
References: <521537B1.703@HIDDEN>
In-Reply-To: <521537B1.703@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

The -g and -h options of 'sort' are indeed incompatible; they
result in different outputs.

More generally, these bug reports reargue the 'grep' bug reported here:

http://lists.gnu.org/archive/html/bug-grep/2013-08/msg00017.html

and replied to here:

http://lists.gnu.org/archive/html/bug-grep/2013-08/msg00018.html

Generally speaking, the GNU utilities follow the POSIX utility
syntax guidelines, in particular Guideline 11:

    The order of different options relative to one another
    should not matter, unless the options are documented as
    mutually-exclusive and such an option is documented to
    override any incompatible options preceding it.

    http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02

It sounds like you're disputing the main part of this guideline
and are advocating always taking the second (exceptional) part.
It's not clear to me that this makes sense, and there are
good arguments for sticking with the more-cautious approach.

Message sent to bug-coreutils@HIDDEN:

Subject: bug#15157: bug#15158: sort complains about incompatible options (that aren't) AND when it shouldn't
Resent-From: Linda Walsh <coreutils@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Thu, 22 Aug 2013 01:43:01 +0000
Resent-Message-ID: <handler.15157.B15157.137713576617982 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Paul Eggert <eggert@HIDDEN>
Cc: 15158 <at> debbugs.gnu.org, 15157 <at> debbugs.gnu.org
Message-ID: <52156C80.6050507@HIDDEN>
Date: Wed, 21 Aug 2013 18:42:24 -0700
From: Linda Walsh <coreutils@HIDDEN>
User-Agent: Thunderbird
MIME-Version: 1.0
References: <521537B1.703@HIDDEN> <52155655.9020001@HIDDEN>
In-Reply-To: <52155655.9020001@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>



Paul Eggert wrote:
> The -g and -h options of 'sort' are indeed incompatible; they
> result in different outputs.
> 
> More generally, these bug reports reargue the 'grep' bug reported here:
> http://lists.gnu.org/archive/html/bug-grep/2013-08/msg00017.html
---
	Not really.  There was nothing about the similarity and
overlap of sort options and how integer is still in the class
of general numbers, which includes 'e' as an abbreviation for
a power prefix, just like KMG are power prefixes as well.

	You can't claim that 3.2e+3, where e indicates some
power of 10 follows, and is used  as a scaling factor for 3.2 is
that different from 3.2k, where k is a scaling factor, and, indicates
that 3.2 is scaled by a factor of 10**3.

	They are both general numeric cases... I don't think
I had anything to say, at all, about the overlap of such in grep,
which is inconsistent with itself:

   grep -d read -d skip --color=auto --color=always  foo
(no error)...

   GREP_OPTIONS="-d skip --color=auto -P"
   grep -E "this|that"
   grep: conflicting matchers specified
???
I didn't specify them on the command line -- OR now:
    egrep "this|that"
    egrep: egrep can only use the egrep pattern syntax
But I didn't specify any other syntax... oh.. it reads the cmdline
options of 'grep', but it can't function like grep?  That sounds
a bit ill-designed.

-------
Please don't try to take over and confused bugs on other utils, just
to put forth your view that utilities should default to broken unless
the user invokes them perfectly.

That's a bad User Interface design -- computers are supposed to
be there to help us -- not to enable those who enjoy making others
wrong to do so on a wide scale.


> 
> and replied to here:
> 
> http://lists.gnu.org/archive/html/bug-grep/2013-08/msg00018.html
> 
> Generally speaking, the GNU utilities follow the POSIX utility
> syntax guidelines, in particular Guideline 11:
> 
>     The order of different options relative to one another
>     should not matter, unless the options are documented as
>     mutually-exclusive and such an option is documented to
>     override any incompatible options preceding it.
> 
>     http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02
> 
> It sounds like you're disputing the main part of this guideline
> and are advocating always taking the second (exceptional) part.
---
The 2nd part has been the norm.  While you are claiming that the
exceptional design should be the norm.

Let me know how specifying your options out of order on gnu tar works
out... There are many contexts where one option enables or disables
others.  The idea that options should be order independent is as
absurd as the idea that the lines in a "C" program should also be order
independent.  This is a perfect example of the ivory tower thinking that
is dominating POSIX now.  While they used to be more practical and describe
what was, now they've jump to the forefront to dictate bad design and
dumbed-down interfaces.   Have you ever thought about the fact that they are
funded by Corporations who might have an interest in seeing Linux's
open nature be killed off -- and/or it's usage reduced?


> It's not clear to me that this makes sense, and there are
> good arguments for sticking with the more-cautious approach.
----
So you have said, but name some that would be true for most people and
make more sense than the previous, deterministic approach...

As it is, I could point to sources by "them" and talk about what
"they" said and "everyone knows"... to make my point, but I'll
rely on the common sense that most people have in knowing that
having programs that are resilient in the face of odd
user input and have it do something useful and predictable
is far better than having fragile programs that break on all
but perfect input.

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#15157: join doesn't follow norms and dies instead of doing something useful w/duplicate options
Resent-From: =?UTF-8?Q?P=C3=A1draig?= Brady <P@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Thu, 22 Aug 2013 03:56:02 +0000
Resent-Message-ID: <handler.15157.B15157.13771437441995 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15157
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: 
To: Linda Walsh <coreutils@HIDDEN>
Cc: 15157 <at> debbugs.gnu.org
Received: via spool by 15157-submit <at> debbugs.gnu.org id=B15157.13771437441995
          (code B ref 15157); Thu, 22 Aug 2013 03:56:02 +0000
Received: (at 15157) by debbugs.gnu.org; 22 Aug 2013 03:55:44 +0000
Received: from localhost ([127.0.0.1]:46396 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1VCLzr-0000W6-Nt
	for submit <at> debbugs.gnu.org; Wed, 21 Aug 2013 23:55:44 -0400
Received: from mail3.vodafone.ie ([213.233.128.45]:40235)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <P@HIDDEN>) id 1VCLzp-0000Vy-PQ
 for 15157 <at> debbugs.gnu.org; Wed, 21 Aug 2013 23:55:42 -0400
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApQBAOuKFVJtTh9r/2dsb2JhbAANTYcmuV+CfIEzgxgBAQEDASMPAUYFCwsNAQoCAgUUAgQHAgIJAwIBAgFFBg0BBwEBiAaiaHSKWYEpjy4HgmiBLAOeMYxrgTw
Received: from unknown (HELO [192.168.1.79]) ([109.78.31.107])
 by mail3.vodafone.ie with ESMTP; 22 Aug 2013 04:55:40 +0100
Message-ID: <52158BBB.7070803@HIDDEN>
Date: Thu, 22 Aug 2013 04:55:39 +0100
From: =?UTF-8?Q?P=C3=A1draig?= Brady <P@HIDDEN>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
References: <521534DA.5040302@HIDDEN>
In-Reply-To: <521534DA.5040302@HIDDEN>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

On 08/21/2013 10:44 PM, Linda Walsh wrote:
> 
> join is inconsistent with other utils (like cut, for example) in how
> it handles a specification of a switch value that has already been
> set.
> 
> 1) if a switch is set more than once with the same value, it
> doesn't complain, but if the options differ, unlike utilities
> like 'cut', the tool dies rather than taking the final
> specification as what is meant.
> 
> ex:
>    cut -d'<TAB>' -d: -f1 </etc/passwd
> doesn't issue any errors.

nor does `numfmt -d`

> But the same thing with join:
> join -t'<TAB>' -t: -f1 /etc/passwd /etc/group
> join: incompatible tabs
> 
> ???  tabs?  they are field separators.

I agree, the error is badly worded.
Note also that `sort -t` follows the `join` behavior.

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

So it is debatable as to whether this should be changed.
The utilities should at least be consistent with each other,
and if possible other systems. So in this case I'm inclined
to allow multiple field sep options and document that
the last takes precedence.

New users of these tools may be caught out though.
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.

thanks,
Pádraig.

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#15157: join doesn't follow norms and dies instead of doing something useful w/duplicate options
Resent-From: Linda Walsh <coreutils@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Thu, 22 Aug 2013 04:56:02 +0000
Resent-Message-ID: <handler.15157.B15157.13771473057590 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15157
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?P=C3=A1draig?= Brady <P@HIDDEN>
Cc: 15127 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>, 15157 <at> debbugs.gnu.org
Received: via spool by 15157-submit <at> debbugs.gnu.org id=B15157.13771473057590
          (code B ref 15157); Thu, 22 Aug 2013 04:56:02 +0000
Received: (at 15157) by debbugs.gnu.org; 22 Aug 2013 04:55:05 +0000
Received: from localhost ([127.0.0.1]:46493 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1VCMvH-0001yF-Ni
	for submit <at> debbugs.gnu.org; Thu, 22 Aug 2013 00:55:04 -0400
Received: from ishtar.tlinx.org ([173.164.175.65]:45758)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <coreutils@HIDDEN>)
 id 1VCMvB-0001xd-M5; Thu, 22 Aug 2013 00:54:58 -0400
Received: from [192.168.4.12] (Athenae [192.168.4.12])
 by Ishtar.tlinx.org (8.14.7/8.14.4/SuSE Linux 0.8) with ESMTP id
 r7M4snrh096082; Wed, 21 Aug 2013 21:54:51 -0700
Message-ID: <52159999.7000402@HIDDEN>
Date: Wed, 21 Aug 2013 21:54:49 -0700
From: Linda Walsh <coreutils@HIDDEN>
User-Agent: Thunderbird
MIME-Version: 1.0
References: <521534DA.5040302@HIDDEN> <52158BBB.7070803@HIDDEN>
In-Reply-To: <52158BBB.7070803@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.8 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.8 (--)



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 sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#15157: bug#15127: bug#15157: join doesn't follow norms and dies instead of doing something useful w/duplicate options
Resent-From: Eric Blake <eblake@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Thu, 22 Aug 2013 12:43:03 +0000
Resent-Message-ID: <handler.15157.B15157.137717535724097 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15157
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: 
To: Linda Walsh <coreutils@HIDDEN>
Cc: 15127 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>, =?UTF-8?Q?P=C3=A1draig?= Brady <P@HIDDEN>, 15157 <at> debbugs.gnu.org
Received: via spool by 15157-submit <at> debbugs.gnu.org id=B15157.137717535724097
          (code B ref 15157); Thu, 22 Aug 2013 12:43:03 +0000
Received: (at 15157) by debbugs.gnu.org; 22 Aug 2013 12:42:37 +0000
Received: from localhost ([127.0.0.1]:47203 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1VCUDi-0006GS-KK
	for submit <at> debbugs.gnu.org; Thu, 22 Aug 2013 08:42:35 -0400
Received: from mx1.redhat.com ([209.132.183.28]:63871)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eblake@HIDDEN>)
 id 1VCUDd-0006G8-HU; Thu, 22 Aug 2013 08:42:31 -0400
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
 (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
 by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r7MCgPfL001950
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
 Thu, 22 Aug 2013 08:42:26 -0400
Received: from [10.3.113.37] (ovpn-113-37.phx2.redhat.com [10.3.113.37])
 by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id
 r7MCUBNW015683; Thu, 22 Aug 2013 08:30:22 -0400
Message-ID: <52160451.2020905@HIDDEN>
Date: Thu, 22 Aug 2013 06:30:09 -0600
From: Eric Blake <eblake@HIDDEN>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
References: <521534DA.5040302@HIDDEN> <52158BBB.7070803@HIDDEN>
 <52159999.7000402@HIDDEN>
In-Reply-To: <52159999.7000402@HIDDEN>
X-Enigmail-Version: 1.5.2
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="nQ660WGT6U3Tmo84U884w9QrWjxPTDhvQ"
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
X-Spam-Score: -7.8 (-------)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -7.8 (-------)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--nQ660WGT6U3Tmo84U884w9QrWjxPTDhvQ
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.

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


--nQ660WGT6U3Tmo84U884w9QrWjxPTDhvQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJSFgRSAAoJEKeha0olJ0NqKeAH/RjZUFPqYi2VdIjoUaMo7GWy
o1owu9pj8IQHVWdGahbJHTWhlLQB42BqqOhtu31DgmZWxOWLMFTkhyCxVtTqpeQm
G4YuOSelFT+xuVvLI0z6nqiSu87PXQDlDGgdeg2q24Oy9qjgTG52So/I9qfmaIgT
TjKPbL5cPyI42pDet9ipDYdVrQxXmL3OoplgJpoMuFyGsHq1yZfH9oewsrBZR7/1
a4cHaYUNkxh5rZO5JguAYpgXn/g8WtbL7zWEZgVV5Ibp7+UDgAcbmULrl0gPlBah
7ctvUpV310josOGuAksFuoMDkC+Spfcyl8QySpCD0mgHJBXv4Vfw77I6pRuHRo4=
=ig3b
-----END PGP SIGNATURE-----

--nQ660WGT6U3Tmo84U884w9QrWjxPTDhvQ--

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#15157: bug#15127: grep not taking last conflicting option as choice?
Resent-From: Linda Walsh <coreutils@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Thu, 22 Aug 2013 22:19:02 +0000
Resent-Message-ID: <handler.15157.B15157.137720993016633 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15157
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: 
To: Eric Blake <eblake@HIDDEN>
Cc: 15127 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>, =?UTF-8?Q?P=C3=A1draig?= Brady <P@HIDDEN>, 15157 <at> debbugs.gnu.org
Received: via spool by 15157-submit <at> debbugs.gnu.org id=B15157.137720993016633
          (code B ref 15157); Thu, 22 Aug 2013 22:19:02 +0000
Received: (at 15157) by debbugs.gnu.org; 22 Aug 2013 22:18:50 +0000
Received: from localhost ([127.0.0.1]:48576 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1VCdDN-0004KB-6v
	for submit <at> debbugs.gnu.org; Thu, 22 Aug 2013 18:18:49 -0400
Received: from ishtar.tlinx.org ([173.164.175.65]:50588)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <coreutils@HIDDEN>)
 id 1VCdDJ-0004Jw-4m; Thu, 22 Aug 2013 18:18:47 -0400
Received: from [192.168.4.12] (Athenae [192.168.4.12])
 by Ishtar.tlinx.org (8.14.7/8.14.4/SuSE Linux 0.8) with ESMTP id
 r7MMIU27044528; Thu, 22 Aug 2013 15:18:33 -0700
Message-ID: <52168E36.8080207@HIDDEN>
Date: Thu, 22 Aug 2013 15:18:30 -0700
From: Linda Walsh <coreutils@HIDDEN>
User-Agent: Thunderbird
MIME-Version: 1.0
References: <521534DA.5040302@HIDDEN> <52158BBB.7070803@HIDDEN>
 <52159999.7000402@HIDDEN> <52160451.2020905@HIDDEN>
In-Reply-To: <52160451.2020905@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.8 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.8 (--)



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 sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#15157: bug#15127: grep not taking last conflicting option as choice?
Resent-From: Paul Eggert <eggert@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Thu, 22 Aug 2013 23:29:02 +0000
Resent-Message-ID: <handler.15157.B15157.137721408423064 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15157
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: 
To: Linda Walsh <coreutils@HIDDEN>
Cc: 15127 <at> debbugs.gnu.org, 15157 <at> debbugs.gnu.org
Received: via spool by 15157-submit <at> debbugs.gnu.org id=B15157.137721408423064
          (code B ref 15157); Thu, 22 Aug 2013 23:29:02 +0000
Received: (at 15157) by debbugs.gnu.org; 22 Aug 2013 23:28:04 +0000
Received: from localhost ([127.0.0.1]:48698 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1VCeIN-0005zq-KW
	for submit <at> debbugs.gnu.org; Thu, 22 Aug 2013 19:28:04 -0400
Received: from smtp.cs.ucla.edu ([131.179.128.62]:60402)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eggert@HIDDEN>)
 id 1VCeIJ-0005zJ-Ll; Thu, 22 Aug 2013 19:28:00 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
 by smtp.cs.ucla.edu (Postfix) with ESMTP id 89B2839E810E;
 Thu, 22 Aug 2013 16:27:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu
Received: from smtp.cs.ucla.edu ([127.0.0.1])
 by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id rhEHDtHC+XnK; Thu, 22 Aug 2013 16:27:58 -0700 (PDT)
Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200])
 by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 2DEBC39E8105;
 Thu, 22 Aug 2013 16:27:58 -0700 (PDT)
Message-ID: <52169E7D.1050404@HIDDEN>
Date: Thu, 22 Aug 2013 16:27:57 -0700
From: Paul Eggert <eggert@HIDDEN>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
References: <521534DA.5040302@HIDDEN> <52158BBB.7070803@HIDDEN>
 <52159999.7000402@HIDDEN> <52160451.2020905@HIDDEN>
 <52168E36.8080207@HIDDEN>
In-Reply-To: <52168E36.8080207@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: -5.1 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.1 (-----)

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 sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#15157: bug#15127: grep not taking last conflicting option as choice?
Resent-From: Eric Blake <eblake@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Fri, 23 Aug 2013 00:10:03 +0000
Resent-Message-ID: <handler.15157.B15157.137721654326880 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15157
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: 
To: Linda Walsh <coreutils@HIDDEN>
Cc: 15127 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>, =?UTF-8?Q?P=C3=A1draig?= Brady <P@HIDDEN>, 15157 <at> debbugs.gnu.org
Received: via spool by 15157-submit <at> debbugs.gnu.org id=B15157.137721654326880
          (code B ref 15157); Fri, 23 Aug 2013 00:10:03 +0000
Received: (at 15157) by debbugs.gnu.org; 23 Aug 2013 00:09:03 +0000
Received: from localhost ([127.0.0.1]:48750 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1VCew3-0006zP-6i
	for submit <at> debbugs.gnu.org; Thu, 22 Aug 2013 20:09:03 -0400
Received: from mx1.redhat.com ([209.132.183.28]:27082)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eblake@HIDDEN>)
 id 1VCevy-0006yo-Cl; Thu, 22 Aug 2013 20:08:59 -0400
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
 (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
 by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r7N08ngQ030870
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
 Thu, 22 Aug 2013 20:08:49 -0400
Received: from [10.3.113.37] (ovpn-113-37.phx2.redhat.com [10.3.113.37])
 by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
 r7N08nlj011012; Thu, 22 Aug 2013 20:08:49 -0400
Message-ID: <5216A810.8030004@HIDDEN>
Date: Thu, 22 Aug 2013 18:08:48 -0600
From: Eric Blake <eblake@HIDDEN>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
References: <521534DA.5040302@HIDDEN> <52158BBB.7070803@HIDDEN>
 <52159999.7000402@HIDDEN> <52160451.2020905@HIDDEN>
 <52168E36.8080207@HIDDEN>
In-Reply-To: <52168E36.8080207@HIDDEN>
X-Enigmail-Version: 1.5.2
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="CvlFQ0aT3sCqsMKwA0DLfksWHLQ3eJL0A"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
X-Spam-Score: -7.8 (-------)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -7.8 (-------)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--CvlFQ0aT3sCqsMKwA0DLfksWHLQ3eJL0A
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 enforc=
e
> 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.=20
> ---
>     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=C3=A1draig mentioned, we are lookin=
g at
what could be done as an improvement in quality of implementation.

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

--CvlFQ0aT3sCqsMKwA0DLfksWHLQ3eJL0A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJSFqgRAAoJEKeha0olJ0NqJEcH/imvrXuL4/67hKkbtSECquqU
gstLCPtL4LOmemLczUWahrQKXhv/F7eJgwVQa8qaMzlZjtNNAkj7YcTYryiwx8Wb
ffO3Z3aD6pph64r/kfIGazeu3IcP+N2fuXiTJDiXhKPnehJ0gRBCjvT+Yy4Ro/y1
HesPNZH7TzWzY96SCCRjG6fY073+1u++tFwglMtYTYrLRLZbgNfkvXEFF5OT4DlD
02OwjqCIP36csqKpunpr5GgVf9uHBH/rENHixCzVFVXpA4K4eUZICnkjmd8ldi8d
37s1XrP5gwzanPw+8CXjh1XQOj73hoEHI7Vf+p+j4Y/KMszKEssxN8hpl+BvpIo=
=4lhK
-----END PGP SIGNATURE-----

--CvlFQ0aT3sCqsMKwA0DLfksWHLQ3eJL0A--

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#15157: bug#15127: grep not taking last conflicting option as choice?
Resent-From: Linda Walsh <coreutils@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Fri, 23 Aug 2013 01:44:02 +0000
Resent-Message-ID: <handler.15157.B15157.13772222113073 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15157
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: 
To: Eric Blake <eblake@HIDDEN>
Cc: 15127 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>, =?UTF-8?Q?P=C3=A1draig?= Brady <P@HIDDEN>, 15157 <at> debbugs.gnu.org
Received: via spool by 15157-submit <at> debbugs.gnu.org id=B15157.13772222113073
          (code B ref 15157); Fri, 23 Aug 2013 01:44:02 +0000
Received: (at 15157) by debbugs.gnu.org; 23 Aug 2013 01:43:31 +0000
Received: from localhost ([127.0.0.1]:48913 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1VCgPP-0000nQ-72
	for submit <at> debbugs.gnu.org; Thu, 22 Aug 2013 21:43:31 -0400
Received: from ishtar.tlinx.org ([173.164.175.65]:55834)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <coreutils@HIDDEN>)
 id 1VCgPI-0000n7-NR; Thu, 22 Aug 2013 21:43:25 -0400
Received: from [192.168.4.12] (Athenae [192.168.4.12])
 by Ishtar.tlinx.org (8.14.7/8.14.4/SuSE Linux 0.8) with ESMTP id
 r7N1h4ZG083877; Thu, 22 Aug 2013 18:43:09 -0700
Message-ID: <5216BE29.9060804@HIDDEN>
Date: Thu, 22 Aug 2013 18:43:05 -0700
From: Linda Walsh <coreutils@HIDDEN>
User-Agent: Thunderbird
MIME-Version: 1.0
References: <521534DA.5040302@HIDDEN> <52158BBB.7070803@HIDDEN>
 <52159999.7000402@HIDDEN> <52160451.2020905@HIDDEN>
 <52168E36.8080207@HIDDEN> <5216A810.8030004@HIDDEN>
In-Reply-To: <5216A810.8030004@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.8 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.8 (--)



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 sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#15157: bug#15127: grep not taking last conflicting option as choice?
Resent-From: Eric Blake <eblake@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Fri, 23 Aug 2013 02:39:03 +0000
Resent-Message-ID: <handler.15157.B15157.13772255388401 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15157
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: 
To: Linda Walsh <coreutils@HIDDEN>
Cc: 15127 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>, =?UTF-8?Q?P=C3=A1draig?= Brady <P@HIDDEN>, 15157 <at> debbugs.gnu.org
Received: via spool by 15157-submit <at> debbugs.gnu.org id=B15157.13772255388401
          (code B ref 15157); Fri, 23 Aug 2013 02:39:03 +0000
Received: (at 15157) by debbugs.gnu.org; 23 Aug 2013 02:38:58 +0000
Received: from localhost ([127.0.0.1]:48993 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1VChH4-0002BJ-FM
	for submit <at> debbugs.gnu.org; Thu, 22 Aug 2013 22:38:58 -0400
Received: from mx1.redhat.com ([209.132.183.28]:2928)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eblake@HIDDEN>)
 id 1VChGt-0002Aw-A5; Thu, 22 Aug 2013 22:38:47 -0400
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
 (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
 by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r7N2cgBx017763
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
 Thu, 22 Aug 2013 22:38:42 -0400
Received: from [10.3.113.37] (ovpn-113-37.phx2.redhat.com [10.3.113.37])
 by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
 r7N2cfNE002331; Thu, 22 Aug 2013 22:38:41 -0400
Message-ID: <5216CB31.5050302@HIDDEN>
Date: Thu, 22 Aug 2013 20:38:41 -0600
From: Eric Blake <eblake@HIDDEN>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
References: <521534DA.5040302@HIDDEN> <52158BBB.7070803@HIDDEN>
 <52159999.7000402@HIDDEN> <52160451.2020905@HIDDEN>
 <52168E36.8080207@HIDDEN> <5216A810.8030004@HIDDEN>
 <5216BE29.9060804@HIDDEN>
In-Reply-To: <5216BE29.9060804@HIDDEN>
X-Enigmail-Version: 1.5.2
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="1OE7XilF5BI2UqrawC2jSmCbnPCqFpUFr"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
X-Spam-Score: -7.8 (-------)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -7.8 (-------)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--1OE7XilF5BI2UqrawC2jSmCbnPCqFpUFr
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 a=
re
> 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.

>=20
> and responded to here:
> http://lists.gnu.org/archive/html/bug-grep/2013-08/msg00018.html
>=20
> 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=
=2E

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

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


--1OE7XilF5BI2UqrawC2jSmCbnPCqFpUFr
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJSFssxAAoJEKeha0olJ0Nq2YMIAJSiP7YwIB+nGDaxAMPiPnAl
n4YbRW2t9xEkvual+yVWBjovTZ/73ZWLmeiZMhcJDekl4fpnF9OuTmjlZcusEbRV
mk5uD6/cpSQyd+OF6I4wHsERhwb4W8qE1cz2kr4PWPYxBqp5gNYA+yXe2WMGWjvg
PqUKlvIuAkZMrP4IR4420jv6oD8KlquIHcq+ryT0XiJCSgzHrhrlMKOzlEX3hQ6h
2bEKpDGeByNjAbPgLXsumDLkB/vlJtR6GNLaHxvGmRllhitOJASlFzjdHuRFTYn+
PXj7MyxZeWZh/U2LrsXmwTLBWtzy4y5uYq50thFYZt9aSOKvYKqCOnWYUCuz5x0=
=TC8K
-----END PGP SIGNATURE-----

--1OE7XilF5BI2UqrawC2jSmCbnPCqFpUFr--

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

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