Received: (at 15157) by debbugs.gnu.org; 23 Aug 2013 02:38:58 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 22 22:38:58 2013 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 To: Linda Walsh <coreutils@HIDDEN> Subject: Re: bug#15127: grep not taking last conflicting option as choice? 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-Debbugs-Envelope-To: 15157 Cc: 15127 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>, =?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?= <P@HIDDEN>, 15157 <at> debbugs.gnu.org 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--
bug-coreutils@HIDDEN:bug#15157; Package coreutils.
Full text available.
Received: (at 15157) by debbugs.gnu.org; 23 Aug 2013 01:43:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 22 21:43:31 2013
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
To: Eric Blake <eblake@HIDDEN>
Subject: Re: bug#15127: grep not taking last conflicting option as choice?
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-Debbugs-Envelope-To: 15157
Cc: 15127 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>, Pádraig Brady <P@HIDDEN>, 15157 <at> debbugs.gnu.org
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.
bug-coreutils@HIDDEN:bug#15157; Package coreutils.
Full text available.Received: (at 15157) by debbugs.gnu.org; 23 Aug 2013 00:09:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 22 20:09:03 2013 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 To: Linda Walsh <coreutils@HIDDEN> Subject: Re: bug#15127: grep not taking last conflicting option as choice? 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-Debbugs-Envelope-To: 15157 Cc: 15127 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>, =?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?= <P@HIDDEN>, 15157 <at> debbugs.gnu.org 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--
bug-coreutils@HIDDEN:bug#15157; Package coreutils.
Full text available.Received: (at 15157) by debbugs.gnu.org; 22 Aug 2013 23:28:04 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 22 19:28:04 2013 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 To: Linda Walsh <coreutils@HIDDEN> Subject: Re: bug#15127: grep not taking last conflicting option as choice? 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-Debbugs-Envelope-To: 15157 Cc: 15127 <at> debbugs.gnu.org, 15157 <at> debbugs.gnu.org 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.
bug-coreutils@HIDDEN:bug#15157; Package coreutils.
Full text available.Received: (at 15157) by debbugs.gnu.org; 22 Aug 2013 22:18:50 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 22 18:18:50 2013 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 To: Eric Blake <eblake@HIDDEN> Subject: Re: bug#15127: grep not taking last conflicting option as choice? 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-Debbugs-Envelope-To: 15157 Cc: 15127 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>, Pádraig Brady <P@HIDDEN>, 15157 <at> debbugs.gnu.org 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.
bug-coreutils@HIDDEN:bug#15157; Package coreutils.
Full text available.Received: (at 15157) by debbugs.gnu.org; 22 Aug 2013 12:42:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 22 08:42:37 2013 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 To: Linda Walsh <coreutils@HIDDEN> Subject: Re: bug#15127: bug#15157: join doesn't follow norms and dies instead of doing something useful w/duplicate options 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-Debbugs-Envelope-To: 15157 Cc: 15127 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>, =?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?= <P@HIDDEN>, 15157 <at> debbugs.gnu.org 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--
bug-coreutils@HIDDEN:bug#15157; Package coreutils.
Full text available.Received: (at 15157) by debbugs.gnu.org; 22 Aug 2013 04:55:05 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 22 00:55:05 2013 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 To: Pádraig Brady <P@HIDDEN> Subject: Re: bug#15157: join doesn't follow norms and dies instead of doing something useful w/duplicate options 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-Debbugs-Envelope-To: 15157 Cc: 15127 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>, 15157 <at> debbugs.gnu.org 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...
bug-coreutils@HIDDEN:bug#15157; Package coreutils.
Full text available.Received: (at 15157) by debbugs.gnu.org; 22 Aug 2013 03:55:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Aug 21 23:55:44 2013 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?B?UMOhZHJhaWcgQnJhZHk=?= <P@HIDDEN> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Linda Walsh <coreutils@HIDDEN> Subject: Re: bug#15157: join doesn't follow norms and dies instead of doing something useful w/duplicate options 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-Debbugs-Envelope-To: 15157 Cc: 15157 <at> debbugs.gnu.org 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.
bug-coreutils@HIDDEN:bug#15157; Package coreutils.
Full text available.
Received: (at 15157) by debbugs.gnu.org; 22 Aug 2013 01:42:46 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Aug 21 21:42:46 2013
Received: from localhost ([127.0.0.1]:46181 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1VCJvC-0004fs-7w
for submit <at> debbugs.gnu.org; Wed, 21 Aug 2013 21:42:46 -0400
Received: from ishtar.tlinx.org ([173.164.175.65]:39661)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <coreutils@HIDDEN>)
id 1VCJv7-0004fc-IR; Wed, 21 Aug 2013 21:42:43 -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
r7M1gOPr056601; Wed, 21 Aug 2013 18:42:26 -0700
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
To: Paul Eggert <eggert@HIDDEN>
Subject: Re: bug#15158: sort complains about incompatible options (that
aren't) AND when it shouldn't
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
X-Spam-Score: -2.8 (--)
X-Debbugs-Envelope-To: 15157
Cc: 15158 <at> debbugs.gnu.org, 15157 <at> debbugs.gnu.org
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 (--)
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.
bug-coreutils@HIDDEN:bug#15157; Package coreutils.
Full text available.
Received: (at 15157) by debbugs.gnu.org; 22 Aug 2013 00:07:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Aug 21 20:07:55 2013
Received: from localhost ([127.0.0.1]:46062 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1VCIRO-0002Hs-Fr
for submit <at> debbugs.gnu.org; Wed, 21 Aug 2013 20:07:54 -0400
Received: from smtp.cs.ucla.edu ([131.179.128.62]:36968)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <eggert@HIDDEN>)
id 1VCIRL-0002Hg-8g; Wed, 21 Aug 2013 20:07:52 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
by smtp.cs.ucla.edu (Postfix) with ESMTP id 8039E39E810A;
Wed, 21 Aug 2013 17:07:50 -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 ojNEvYdnlj17; Wed, 21 Aug 2013 17:07:49 -0700 (PDT)
Received: from [192.168.1.9] (pool-71-108-49-126.lsanca.fios.verizon.net
[71.108.49.126])
by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 96FE839E8008;
Wed, 21 Aug 2013 17:07:49 -0700 (PDT)
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
To: Linda Walsh <coreutils@HIDDEN>
Subject: Re: bug#15158: sort complains about incompatible options (that aren't)
AND when it shouldn't
References: <521537B1.703@HIDDEN>
In-Reply-To: <521537B1.703@HIDDEN>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: -5.1 (-----)
X-Debbugs-Envelope-To: 15157
Cc: 15158 <at> debbugs.gnu.org, 15157 <at> debbugs.gnu.org
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 (-----)
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.
bug-coreutils@HIDDEN:bug#15157; Package coreutils.
Full text available.
Received: (at submit) by debbugs.gnu.org; 21 Aug 2013 21:45:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Aug 21 17:45:30 2013
Received: from localhost ([127.0.0.1]:45888 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1VCGDZ-0007IA-If
for submit <at> debbugs.gnu.org; Wed, 21 Aug 2013 17:45:29 -0400
Received: from eggs.gnu.org ([208.118.235.92]:56777)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <coreutils@HIDDEN>) id 1VCGDX-0007I2-LI
for submit <at> debbugs.gnu.org; Wed, 21 Aug 2013 17:45:27 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <coreutils@HIDDEN>) id 1VCGDO-0007mA-Q7
for submit <at> debbugs.gnu.org; Wed, 21 Aug 2013 17:45:27 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level:
X-Spam-Status: No, score=-99.2 required=5.0 tests=BAYES_50,USER_IN_WHITELIST
autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:59150)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from <coreutils@HIDDEN>) id 1VCGDO-0007m6-NP
for submit <at> debbugs.gnu.org; Wed, 21 Aug 2013 17:45:18 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:58448)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from <coreutils@HIDDEN>) id 1VCGDI-0003vF-I1
for bug-coreutils@HIDDEN; Wed, 21 Aug 2013 17:45:18 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <coreutils@HIDDEN>) id 1VCGDB-0007cD-74
for bug-coreutils@HIDDEN; Wed, 21 Aug 2013 17:45:12 -0400
Received: from ishtar.tlinx.org ([173.164.175.65]:54816)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from <coreutils@HIDDEN>) id 1VCGDA-0007V4-Jk
for bug-coreutils@HIDDEN; Wed, 21 Aug 2013 17:45:05 -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
r7LLivdO008405
for <bug-coreutils@HIDDEN>; Wed, 21 Aug 2013 14:45:00 -0700
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
To: bug-coreutils@HIDDEN
Subject: join doesn't follow norms and dies instead of doing something useful
w/duplicate options
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no
timestamps) [generic]
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
(bad octet value).
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -3.4 (---)
X-Debbugs-Envelope-To: submit
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: -3.4 (---)
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.
Linda Walsh <coreutils@HIDDEN>:bug-coreutils@HIDDEN.
Full text available.bug-coreutils@HIDDEN:bug#15157; Package coreutils.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.