From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 05 00:38:47 2014 Received: (at submit) by debbugs.gnu.org; 5 Apr 2014 04:38:47 +0000 Received: from localhost ([127.0.0.1]:35814 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWINT-0002ID-26 for submit@debbugs.gnu.org; Sat, 05 Apr 2014 00:38:47 -0400 Received: from eggs.gnu.org ([208.118.235.92]:35498) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWINQ-0002I3-7H for submit@debbugs.gnu.org; Sat, 05 Apr 2014 00:38:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WWINP-0001yt-9n for submit@debbugs.gnu.org; Sat, 05 Apr 2014 00:38:43 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, HTML_MESSAGE,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:56034) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WWINP-0001yn-73 for submit@debbugs.gnu.org; Sat, 05 Apr 2014 00:38:43 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37219) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WWINO-0002bt-EK for bug-coreutils@gnu.org; Sat, 05 Apr 2014 00:38:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WWINM-0001yY-As for bug-coreutils@gnu.org; Sat, 05 Apr 2014 00:38:42 -0400 Received: from mail-we0-x233.google.com ([2a00:1450:400c:c03::233]:55835) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WWINM-0001yL-2y for bug-coreutils@gnu.org; Sat, 05 Apr 2014 00:38:40 -0400 Received: by mail-we0-f179.google.com with SMTP id x48so4373712wes.10 for ; Fri, 04 Apr 2014 21:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=KJ6uZwCX1jV029rYWRH/iEzU6C3eFfPM67awdjvc774=; b=hz18KmUPCRRBCDfrJJYFIC24Sob35sTo7PCkAMzUde4UIUwMOwqFMcn8jjFwqUrR8P O8/VLQkZk25yuJuucNlJ06yA1gLNWx4qHstvIF89ahQdEhmeUMEKcU4C6p1HCelTJlsQ nU0AEk//1jXtzYSXyXPiySlc0Ipuu2dBErxeAtZcso/2ii22cnyl4+x9ph5aysSs0Bzt DKb/A8TNuLEubX8IpqPnptvvXAl5dihALW9/V+8AnXER35p9effE5sHkliKWasGsRXXv h8gZgnuDsnHkv6jrT1Dd/+HONiz/0zgi60vhbh+bE7UBpe+RD+lGJJxwjUU5iL0dgmNf LnNQ== MIME-Version: 1.0 X-Received: by 10.194.186.140 with SMTP id fk12mr24202680wjc.47.1396672719234; Fri, 04 Apr 2014 21:38:39 -0700 (PDT) Received: by 10.194.165.65 with HTTP; Fri, 4 Apr 2014 21:38:39 -0700 (PDT) Date: Sat, 5 Apr 2014 07:38:39 +0300 Message-ID: Subject: Sort bug #2 From: Nikos Balkanas To: bug-coreutils@gnu.org Content-Type: multipart/alternative; boundary=047d7bea45184c29e504f644355d X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). 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: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) --047d7bea45184c29e504f644355d Content-Type: text/plain; charset=ISO-8859-1 What about this output? sort -k1 input > out 009 2919 009 3107 0.0 9312 00a 3294 00A 3389 00a 3484 00A 3578 00a 3670 00A 4142 00b 4236 00B 4332 00b 4801 This is no sorting. It is random garbage. Since when 00a < 00B? This utility used to work fine in earlier distributions, until you broke it down. Please return to previous lexicographic mode and cut the "cute" things. Nikos --047d7bea45184c29e504f644355d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Wha= t about this output?

= sort -k1 input > out

009 =A0 =A02919
009 =A0 =A0= 3107
0.0 =A0 =A0 9312
00a =A0 =A03294
00A =A0 =A03389
00a =A0 = =A03484
00A =A0 =A03578
00a =A0 =A0 3670
00A =A0 =A04142
00b =A0 =A04236
00B =A0 =A04332
00b =A0 =A04801

This is no sorting. It = is random garbage. Since when 00a < 00B? This utility used to work fine = in earlier distributions, until you broke it down.

Please return to previous lexi= cographic mode and cut the "cute" things.

Nikos
--047d7bea45184c29e504f644355d-- From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 05 08:23:50 2014 Received: (at control) by debbugs.gnu.org; 5 Apr 2014 12:23:50 +0000 Received: from localhost ([127.0.0.1]:36077 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWPdU-0007qh-TQ for submit@debbugs.gnu.org; Sat, 05 Apr 2014 08:23:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19195) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWPdP-0007qM-1f; Sat, 05 Apr 2014 08:23:44 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s35CNgnj009920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 Apr 2014 08:23:42 -0400 Received: from [10.3.113.163] (ovpn-113-163.phx2.redhat.com [10.3.113.163]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s35CNfAA016675; Sat, 5 Apr 2014 08:23:42 -0400 Message-ID: <533FF5CD.60409@redhat.com> Date: Sat, 05 Apr 2014 06:23:41 -0600 From: Eric Blake Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nikos Balkanas , 17189-done@debbugs.gnu.org Subject: Re: bug#17189: Sort bug #2 References: In-Reply-To: X-Enigmail-Version: 1.6 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EajNBMDwrkvIs6SwjmaJkB3LGNIHabVgw" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Spam-Score: -5.6 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.6 (-----) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EajNBMDwrkvIs6SwjmaJkB3LGNIHabVgw Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable tag 17189 notabug forcemerge 17188 17189 thanks On 04/04/2014 10:38 PM, Nikos Balkanas wrote: > What about this output? What about it? >=20 > sort -k1 input > out >=20 > 009 2919 > 009 3107 > 0.0 9312 > 00a 3294 > 00A 3389 > 00a 3484 > 00A 3578 > 00a 3670 > 00A 4142 > 00b 4236 > 00B 4332 > 00b 4801 >=20 > This is no sorting. It is random garbage. Since when 00a < 00B? This Ever since the en_US.UTF-8 locale defined strcoll() to sort in case-insensitive dictionary order by default. > utility used to work fine in earlier distributions, until you broke it = down. No, earlier distributions merely defaulted to LC_ALL=3DC instead of LC_ALL=3Den_US.UTF-8. This complaint is the same as your previous one, and the solution is the same - if you want sorting by bytes, then ensure that your locale is set to C rather than en_US.UTF-8. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --EajNBMDwrkvIs6SwjmaJkB3LGNIHabVgw 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTP/XNAAoJEKeha0olJ0NqkhIH/jvUPcFVvxK6hugMNr6GRR5t qysf9oHmI59FchSqvEbmAiZ+0HmOx2EsfeOqZdt/wRlyaWjY6qgQfAlOetfgzm3u wG4x78vOp9aZ7lQqJ3jOKfhgtNEA2MjOnQJE2YI2HIe2TEGLsyr5i+/HPs7lcz5m QOyNt12Biia/emVa22ZS+1Un7f3PL0Phzci8dTTNFBJshb2ylLHhj4vnDwEWIJAG WZh0dlkde8hgwytzfaNaP26gY/r9gzJJgJMX6jacXNxvyyf6B19hQY2zn4P3ASQR O5DxMqy72cecT3NHwybw//dv1tmX3u5an7Q22lNB3hhNAjptPXS5G288bYVbOt4= =R4Tr -----END PGP SIGNATURE----- --EajNBMDwrkvIs6SwjmaJkB3LGNIHabVgw-- From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 05 15:19:52 2014 Received: (at 17189-done) by debbugs.gnu.org; 5 Apr 2014 19:19:52 +0000 Received: from localhost ([127.0.0.1]:37065 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWW87-000539-N2 for submit@debbugs.gnu.org; Sat, 05 Apr 2014 15:19:52 -0400 Received: from mail-wi0-f170.google.com ([209.85.212.170]:49307) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWW84-00052z-Qy for 17189-done@debbugs.gnu.org; Sat, 05 Apr 2014 15:19:49 -0400 Received: by mail-wi0-f170.google.com with SMTP id bs8so4237539wib.3 for <17189-done@debbugs.gnu.org>; Sat, 05 Apr 2014 12:19:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VnOYirBIaCEp5GE0kLPrdP3Z3wUwZkh55ZdS+7LEQ4U=; b=gK/okEL4SFSfvY5iXNYNqTBIvX8TgOrU4704V7Wn9Txa0TaGvvCVR0rCdVKnFRrp5Y n8ntLmIvd2fgbvRQycKwXdl1F+oJ6qV1tY5I1oqrT/PWPBf61HRFTBM7qo880dBZTqMg Fq9NCeOCtbDO2hnkxoK2RQ/oRIqjoygJvvHMYk0fVGodrTPCO+naARX+FIouFK0EosVj XzDhqITvbOe8Yn2Wb6bzkFt0ODv2pJA58saxFc4QAqsGn+W0fJ2pTNPuwJpTvv8aBQcG 0BP6h4x+El5WYq7Ugy3G4xbLU2ITvftFZGIboiDj/hfCO3mplJnSZU1EX4H023Tjqc1i EbBg== MIME-Version: 1.0 X-Received: by 10.194.20.65 with SMTP id l1mr29760379wje.39.1396725587869; Sat, 05 Apr 2014 12:19:47 -0700 (PDT) Received: by 10.194.165.65 with HTTP; Sat, 5 Apr 2014 12:19:47 -0700 (PDT) In-Reply-To: <533FF5CD.60409@redhat.com> References: <533FF5CD.60409@redhat.com> Date: Sat, 5 Apr 2014 22:19:47 +0300 Message-ID: Subject: Re: bug#17189: Sort bug #2 From: Nikos Balkanas To: Eric Blake Content-Type: multipart/alternative; boundary=047d7b4512a283877b04f650844e X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17189-done Cc: 17189-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --047d7b4512a283877b04f650844e Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 5, 2014 at 3:23 PM, Eric Blake wrote: > tag 17189 notabug > forcemerge 17188 17189 > thanks > > On 04/04/2014 10:38 PM, Nikos Balkanas wrote: > > What about this output? > > What about it? > > > > > sort -k1 input > out > > > > 009 2919 > > 009 3107 > > 0.0 9312 > > 00a 3294 > > 00A 3389 > > 00a 3484 > > 00A 3578 > > 00a 3670 > > 00A 4142 > > 00b 4236 > > 00B 4332 > > 00b 4801 > > > > This is no sorting. It is random garbage. Since when 00a < 00B? This > > Ever since the en_US.UTF-8 locale defined strcoll() to sort in > case-insensitive dictionary order by default. > > > utility used to work fine in earlier distributions, until you broke it > down. > > No, earlier distributions merely defaulted to LC_ALL=C instead of > LC_ALL=en_US.UTF-8. This complaint is the same as your previous one, > and the solution is the same - if you want sorting by bytes, then ensure > that your locale is set to C rather than en_US.UTF-8. > > Thank you all. As I explained in my previous mail, an update of the man pages is essential. A change in the UI would also be desirable, if the standards allow it. Sorry, about my attitude, but I was getting pretty desperate. Thanks for not flaming. To make it up I will look into updating the man pages ;-) A suggestion. I think that sort should sort text based on the LOCALE of the file, not the system. Couldn't it detect automatically from the text, whether it is is dealing with UTF-8 or iso? If dealing with Iso, it should employ the C Locale > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org > > --047d7b4512a283877b04f650844e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sat= , Apr 5, 2014 at 3:23 PM, Eric Blake <eblake@redhat.com> wro= te:
tag 17189 notabug
forcemerge 17188 17189
thanks

On 04/04/2014 10:38 PM, Nikos Balkanas wrote:
> What about this output?

What about it?

>
> sort -k1 input > out
>
> 009 =A0 =A02919
> 009 =A0 =A03107
> 0.0 =A0 =A0 9312
> 00a =A0 =A03294
> 00A =A0 =A03389
> 00a =A0 =A03484
> 00A =A0 =A03578
> 00a =A0 =A0 3670
> 00A =A0 =A04142
> 00b =A0 =A04236
> 00B =A0 =A04332
> 00b =A0 =A04801
>
> This is no sorting. It is random garbage. Since when 00a < 00B? Thi= s

Ever since the en_US.UTF-8 locale defined strcoll() to sort in
case-insensitive dictionary order by default.

> utility used to work fine in earlier distributions, until you broke it= down.

No, earlier distributions merely defaulted to LC_ALL=3DC instead of
LC_ALL=3Den_US.UTF-8. =A0This complaint is the same as your previous one, and the solution is the same - if you want sorting by bytes, then ensure that your locale is set to C rather than en_US.UTF-8.

Tha= nk you all. As I explained in my previous mail, an update of the man pages = is essential. A change in the UI would also be desirable,
if the standards allow it. Sorry, about my attitude, but I was getting pret= ty desperate. Thanks for not flaming.

To make it up I will look into= updating the man pages ;-)

A suggestion. I think that sort should sort text based on the LOCALE of the= file, not the system. Couldn't it detect automatically from the text, = whether it is is dealing with UTF-8 or iso?
If dealing with Iso, it should employ the C Locale
=A0
--
Eric Blake =A0 eblake redhat com =A0 =A0+1-919-301-3266
Libvirt virtualization library http://libvirt.org


--047d7b4512a283877b04f650844e-- From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 05 16:37:49 2014 Received: (at 17189) by debbugs.gnu.org; 5 Apr 2014 20:37:49 +0000 Received: from localhost ([127.0.0.1]:37096 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWXLY-0007DR-LU for submit@debbugs.gnu.org; Sat, 05 Apr 2014 16:37:49 -0400 Received: from joseki.proulx.com ([216.17.153.58]:44264) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWXLS-0007DE-Ud for 17189@debbugs.gnu.org; Sat, 05 Apr 2014 16:37:43 -0400 Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id 4CE0921235; Sat, 5 Apr 2014 14:37:40 -0600 (MDT) Received: by hysteria.proulx.com (Postfix, from userid 1000) id 133532DCD7; Sat, 5 Apr 2014 14:37:39 -0600 (MDT) Date: Sat, 5 Apr 2014 14:37:39 -0600 From: Bob Proulx To: Nikos Balkanas Subject: Re: bug#17189: Sort bug #2 Message-ID: <20140405203739.GB24780@hysteria.proulx.com> References: <533FF5CD.60409@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 17189 Cc: 17189@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) Nikos Balkanas wrote: > Thank you all. As I explained in my previous mail, an update of the man > pages is essential. A change in the UI would also be desirable, > if the standards allow it. Sorry, about my attitude, but I was getting > pretty desperate. Thanks for not flaming. > > To make it up I will look into updating the man pages ;-) Hopefully you will then see the WARNING section in the man page. *** WARNING *** The locale specified by the environment affects sort order. Set LC_ALL=C to get the traditional sort order that uses native byte values. The sort documentation says this: Unless otherwise specified, all comparisons use the character collating sequence specified by the `LC_COLLATE' locale.(1) ... (1) If you use a non-POSIX locale (e.g., by setting `LC_ALL' to `en_US'), then `sort' may produce output that is sorted differently than you're accustomed to. In that case, set the `LC_ALL' environment variable to `C'. Note that setting only `LC_COLLATE' has two problems. First, it is ineffective if `LC_ALL' is also set. Second, it has undefined behavior if `LC_CTYPE' (or `LANG', if `LC_CTYPE' is unset) is set to an incompatible value. For example, you get undefined behavior if `LC_CTYPE' is `ja_JP.PCK' but `LC_COLLATE' is `en_US.UTF-8'. > A suggestion. I think that sort should sort text based on the LOCALE > of the file, not the system. Couldn't it detect automatically from > the text, whether it is is dealing with UTF-8 or iso? If dealing > with Iso, it should employ the C Locale US-ASCII is a subset of UTF-8. Every ASCII file is also a valid UTF-8 file. That is by design. But it also makes it impossible to make an assumption like this. For example one would start out with: Lorem ipsum dolor sit amet Now is the time. Don't look Ethyl! That file would sort one way. Then someone would change the apostrophe to the unicode one. Lorem ipsum dolor sit amet Now is the time. Don’t look Ethel! If sort tried to automatically detect behavior based upon the file content then now the file will sort with dictionary sort ordering? I think this would cause a large number of complaints. It would be data dependent behavior and would break a lot of things. Plus this would require sort to add another pass to read the file first to determine this before applying sorting it. Please no. Besides... One person's file of human language is another person's file of raw bytes. Can't make assumptions like this. Bob From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 05 17:09:18 2014 Received: (at 17189) by debbugs.gnu.org; 5 Apr 2014 21:09:18 +0000 Received: from localhost ([127.0.0.1]:37117 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWXq1-00086o-Dc for submit@debbugs.gnu.org; Sat, 05 Apr 2014 17:09:18 -0400 Received: from mail-we0-f182.google.com ([74.125.82.182]:34679) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWXpy-00086e-7d for 17189@debbugs.gnu.org; Sat, 05 Apr 2014 17:09:15 -0400 Received: by mail-we0-f182.google.com with SMTP id p61so5050119wes.27 for <17189@debbugs.gnu.org>; Sat, 05 Apr 2014 14:09:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=npsNALosDCZjXDTsdZthyJuSiJ3xjG8tFudhX5pz/hk=; b=TekPuAia1/bVXo7nZbwAeVly6ENlBifIbY9xW3fGUxRXq6XNdIhv6XsIptAD04uIEO iJx2kQO7HwB7oZ8bQx67xEaVt2JRsV56l8SYCmfRSf5tZ94vchM+/3UsFkBcpOWH8mSE HCxj4/+BxDcmwnje0TbkrmmYxmNiYhJktsgv1Kp6VOcnvYSBkXrGiV5QpOcecfgOSTgI Nev22ewT8U+eDBy6qkdGKYXi5SmaAFubePt7TiEJ4W6WcPMxNV/NBHk7qocjJp5mK1/q nUJ3NE53dOQlQ96B+vFTmekmgDJK/92TQCkNhvUdNSLOUmmd3+BbE5/UyQ+y+x13uULL 1OsQ== MIME-Version: 1.0 X-Received: by 10.194.58.79 with SMTP id o15mr30834606wjq.62.1396732153236; Sat, 05 Apr 2014 14:09:13 -0700 (PDT) Received: by 10.194.165.65 with HTTP; Sat, 5 Apr 2014 14:09:13 -0700 (PDT) In-Reply-To: <20140405203739.GB24780@hysteria.proulx.com> References: <533FF5CD.60409@redhat.com> <20140405203739.GB24780@hysteria.proulx.com> Date: Sun, 6 Apr 2014 00:09:13 +0300 Message-ID: Subject: Re: bug#17189: Sort bug #2 From: Nikos Balkanas To: Bob Proulx Content-Type: multipart/alternative; boundary=047d7ba972dad7137404f6520b21 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17189 Cc: 17189@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --047d7ba972dad7137404f6520b21 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 5, 2014 at 11:37 PM, Bob Proulx wrote: > Nikos Balkanas wrote: > > Thank you all. As I explained in my previous mail, an update of the man > > pages is essential. A change in the UI would also be desirable, > > if the standards allow it. Sorry, about my attitude, but I was getting > > pretty desperate. Thanks for not flaming. > > > > To make it up I will look into updating the man pages ;-) > > Hopefully you will then see the WARNING section in the man page. > > *** WARNING *** The locale specified by the environment affects > sort order. Set LC_ALL=C to get the traditional sort order that > uses native byte values. > Or maybe move it to the top. Where it is, after a nearly incomprehensible KEYDEF section, one assumes it has smt to do with KEYDEF :-( Some examples for KEYDEF would also be nice, since the sites I searched for sort use, all gave the wrong -k1. [...snip...] US-ASCII is a subset of UTF-8. Every ASCII file is also a valid UTF-8 > file. That is by design. But it also makes it impossible to make an > assumption like this. > > For example one would start out with: > > Lorem ipsum dolor sit amet > Now is the time. > Don't look Ethyl! > > That file would sort one way. Then someone would change the > apostrophe to the unicode one. > > Lorem ipsum dolor sit amet > Now is the time. > Don't look Ethel! > > If sort tried to automatically detect behavior based upon the file > content then now the file will sort with dictionary sort ordering? I > think this would cause a large number of complaints. It would be data > dependent behavior and would break a lot of things. Plus this would > require sort to add another pass to read the file first to determine > this before applying sorting it. Please no. > > Besides... One person's file of human language is another person's > file of raw bytes. Can't make assumptions like this. > Not assumptions. Facts. If coming across a UTF-8 char you know. This simple logic is inescapable: "Sorting input should be based on the input's locale not the system's" The rest are implementation details. Usually answer would be in the first few lines. Worst case scenario would be to scan the whole input. You obviously have considered it a lot in the past, and don't expect to solve it in this thread. Maybe i can think of smt if you tell me your sorting algorithm. Using qsort? > > Bob > --047d7ba972dad7137404f6520b21 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sat= , Apr 5, 2014 at 11:37 PM, Bob Proulx <bob@proulx.com> wrote:
Nikos Balkanas wrote:
> Thank you all. As I explained in my previous mail, an update of the ma= n
> pages is essential. A change in the UI would also be desirable,
> if the standards allow it. Sorry, about my attitude, but I was getting=
> pretty desperate. Thanks for not flaming.
>
> To make it up I will look into updating the man pages ;-)

Hopefully you will then see the WARNING section in the man page.

   ***  WARNING  ***  The locale specified by the = environment affects
   sort order.  Set LC_ALL=3DC to get the traditional sort o= rder that
   uses native byte values.

Or maybe move it to the to= p. Where it is, after a nearly incomprehensible  KEYDEF section,
=
one assumes it has smt to do with KEYDEF :-(
Some examples for KEYDEF would also be nice, = since the sites I searched for sort use,
all gave the wrong -k1.

[= ...snip...]
 US-ASCII is a subset of UTF-8.  Every ASCII file is also a valid= UTF-8
file.  That is by design.  But it also makes it impossible to mak= e an
assumption like this.

For example one would start out with:

  Lorem ipsum dolor sit amet
  Now is the time.
  Don't look Ethyl!

That file would sort one way.  Then someone would change the
apostrophe to the unicode one.

  Lorem ipsum dolor sit amet
  Now is the time.
  Don’t look Ethel!

If sort tried to automatically detect behavior based upon the file
content then now the file will sort with dictionary sort ordering?  I<= br> think this would cause a large number of complaints.  It would be data=
dependent behavior and would break a lot of things.  Plus this would require sort to add another pass to read the file first to determine
this before applying sorting it.  Please no.

Besides...  One person's file of human language is another person&= #39;s
file of raw bytes.  Can't make assumptions like this.

N= ot assumptions. Facts. If coming across a UTF-8 char you know.
This simple logic is inescapable:
"Sorting input should be based on the input's l= ocale not the system's"

The rest a= re implementation details. Usually answer would be in the first
few lines. Worst case scen= ario would be to scan the whole input.
You obviously have c= onsidered it a lot in the past, and don't expect to
solve it in this thread.
Maybe i can think of smt if you tell me your sorting algorithm. Using qsort= ?

Bob

--047d7ba972dad7137404f6520b21-- From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 07 08:49:58 2014 Received: (at 17189-done) by debbugs.gnu.org; 7 Apr 2014 12:49:58 +0000 Received: from localhost ([127.0.0.1]:38908 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WX8zt-0008Id-9g for submit@debbugs.gnu.org; Mon, 07 Apr 2014 08:49:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:12881) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WX8zq-0008IQ-Ku for 17189-done@debbugs.gnu.org; Mon, 07 Apr 2014 08:49:55 -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 s37CnrZu018598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Apr 2014 08:49:53 -0400 Received: from [10.3.113.132] (ovpn-113-132.phx2.redhat.com [10.3.113.132]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s37CnrmP018805; Mon, 7 Apr 2014 08:49:53 -0400 Message-ID: <53429EF1.1000704@redhat.com> Date: Mon, 07 Apr 2014 06:49:53 -0600 From: Eric Blake Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nikos Balkanas Subject: Re: bug#17189: Sort bug #2 References: <533FF5CD.60409@redhat.com> In-Reply-To: X-Enigmail-Version: 1.6 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pMoTfPDuSsMaGqxHTJtWgPnKRvtKrX3ER" X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Spam-Score: -5.3 (-----) X-Debbugs-Envelope-To: 17189-done Cc: 17189-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.3 (-----) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pMoTfPDuSsMaGqxHTJtWgPnKRvtKrX3ER Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/05/2014 01:19 PM, Nikos Balkanas wrote: >> >> No, earlier distributions merely defaulted to LC_ALL=3DC instead of >> LC_ALL=3Den_US.UTF-8. This complaint is the same as your previous one= , >> and the solution is the same - if you want sorting by bytes, then ensu= re >> that your locale is set to C rather than en_US.UTF-8. >> >> Thank you all. As I explained in my previous mail, an update of the ma= n > pages is essential. A change in the UI would also be desirable, > if the standards allow it. Sorry, about my attitude, but I was getting > pretty desperate. Thanks for not flaming. >=20 > To make it up I will look into updating the man pages ;-) But the man page ALREADY says this: *** WARNING *** The locale specified by the environment affects sort order. Set LC_ALL=3DC to get the traditional sort order that uses= native byte values. What more are you proposing? >=20 > A suggestion. I think that sort should sort text based on the LOCALE of= > the file, not the system. Couldn't it detect automatically from the tex= t, > whether it is is dealing with UTF-8 or iso? Unfortunately, no, this is not possible. You're welcome to try and write a patch to prove me wrong, but people have already had years of experience of using environment variables as the way to tell a program what encoding an input file uses, precisely because there is no other obvious way of determining a file's locale. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --pMoTfPDuSsMaGqxHTJtWgPnKRvtKrX3ER 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTQp7xAAoJEKeha0olJ0NqDccH+wV0G6Z55dqaPVfUJTuyGaWV fF+8G4HvYGsXGJfmupDGrN+iJb9HUEhcgEHfkNkCBROE3EuWnxPPyOLsroopITfZ A77s7dCLqaSzb3d6m987KmV2JH86WztH3Ut2yysX7Ful0dVVnr/Ux3q9aRG3iSZa NNt8dYM4/cqv543KH6Cn6TSP7V4/3WZOKGy5A9hCq/nCsVv4DIF7XkstQG+Fw1n1 f7J71PKx8nWdeCabUNUUkRLhmibb8uWRH5ks36pAHFZQHp3VA3i6m2BtXLvMmn2h wQHKRqt/nRJFUMTIrWRyDutlqJ/T9C9xjkZiSUCsm3BI/UFf863lI+m29Mx56Y0= =DLAS -----END PGP SIGNATURE----- --pMoTfPDuSsMaGqxHTJtWgPnKRvtKrX3ER-- From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 07 14:11:18 2014 Received: (at 17189-done) by debbugs.gnu.org; 7 Apr 2014 18:11:18 +0000 Received: from localhost ([127.0.0.1]:39838 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXE0r-0000IQ-Kt for submit@debbugs.gnu.org; Mon, 07 Apr 2014 14:11:18 -0400 Received: from mail-we0-f180.google.com ([74.125.82.180]:40376) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXE0o-0000IF-FK for 17189-done@debbugs.gnu.org; Mon, 07 Apr 2014 14:11:15 -0400 Received: by mail-we0-f180.google.com with SMTP id p61so7023133wes.25 for <17189-done@debbugs.gnu.org>; Mon, 07 Apr 2014 11:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e/AzdK10CPexZJHtUAahJIAYMuzIQnRBNtMv2nYZm4w=; b=VjnIZC6sr8e9UOU4TbihpjGeVxTZ+S3+nRtW2Xov6KYBOAy6AKjRhqa8MlIOBPcz70 AAzQm8XSox4KZCItoVJTxTJgyI6HMKsvp2mxJnsdsZmQgS/6sKOCXc6VFVkK0RCGyvxS e7e4nrPy+TMZGRLgFzYAzA1tEEQY5LxFbgiYxC/NnN2Fag8BIBKBlSg9QM/IGlKAETad xYekI0o30G4l0bl4EcNhoc7ASE/nQXK3jfdovh3wsucKiKRt9RJQmRRe330SZX5YyuWs NN9x2TQJAiEtAHquihO7bLLdHwUCwXIj236ZtWuHTWvHKpqQjoAnqOsG8Yj4B8wWxLqD BlwA== MIME-Version: 1.0 X-Received: by 10.180.77.129 with SMTP id s1mr26592077wiw.56.1396894273130; Mon, 07 Apr 2014 11:11:13 -0700 (PDT) Received: by 10.194.135.202 with HTTP; Mon, 7 Apr 2014 11:11:13 -0700 (PDT) In-Reply-To: <53429EF1.1000704@redhat.com> References: <533FF5CD.60409@redhat.com> <53429EF1.1000704@redhat.com> Date: Mon, 7 Apr 2014 21:11:13 +0300 Message-ID: Subject: Re: bug#17189: Sort bug #2 From: Nikos Balkanas To: Eric Blake Content-Type: multipart/alternative; boundary=f46d043c801ef0576e04f677ca7d X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17189-done Cc: 17189-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --f46d043c801ef0576e04f677ca7d Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 7, 2014 at 3:49 PM, Eric Blake wrote: > On 04/05/2014 01:19 PM, Nikos Balkanas wrote: > > >> > >> No, earlier distributions merely defaulted to LC_ALL=C instead of > >> LC_ALL=en_US.UTF-8. This complaint is the same as your previous one, > >> and the solution is the same - if you want sorting by bytes, then ensure > >> that your locale is set to C rather than en_US.UTF-8. > >> > >> Thank you all. As I explained in my previous mail, an update of the man > > pages is essential. A change in the UI would also be desirable, > > if the standards allow it. Sorry, about my attitude, but I was getting > > pretty desperate. Thanks for not flaming. > > > > To make it up I will look into updating the man pages ;-) > > But the man page ALREADY says this: > > *** WARNING *** The locale specified by the environment > affects sort > order. Set LC_ALL=C to get the traditional sort order that uses > native > byte values. > > What more are you proposing? > I have already written a patch. It uses the available "-a" command line option to "force" traditional (ascii) sorting. Have updated man pages accordingly. What is the best way to upload it? > > > > > A suggestion. I think that sort should sort text based on the LOCALE of > > the file, not the system. Couldn't it detect automatically from the text, > > whether it is is dealing with UTF-8 or iso? > > Unfortunately, no, this is not possible. You're welcome to try and > write a patch to prove me wrong, but people have already had years of > experience of using environment variables as the way to tell a program > what encoding an input file uses, precisely because there is no other > obvious way of determining a file's locale. > > It is possible. It's been sometime, since I was parsing unicode, but if I remember correctly, a unicode char sets bits in its data to specify continuation. This calls for adaptive sorting based on input. I think Bob already mentioned, that it is not acceptable to do a second pass on the input (worst case scenario) to determine input locale, however, adaptive sorting should not need to. Unfortunately it is considerable effort and I would need to know your sorting algo. Since I don't and have much work to do this period, I wrote the much easier ui patch I talked before. I find it more elegant and easier than changing the environment. If it is acceptable, let me know how to upload it. > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org > > --f46d043c801ef0576e04f677ca7d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon= , Apr 7, 2014 at 3:49 PM, Eric Blake <eblake@redhat.com> wro= te:
On 04/05/2014 01:19 PM, Nikos Balkanas wrote= :

>>
>> No, earlier distributions merely defaulted to LC_ALL=3DC instead o= f
>> LC_ALL=3Den_US.UTF-8. =A0This complaint is the same as your previo= us one,
>> and the solution is the same - if you want sorting by bytes, then = ensure
>> that your locale is set to C rather than en_US.UTF-8.
>>
>> Thank you all. As I explained in my previous mail, an update of th= e man
> pages is essential. A change in the UI would also be desirable,
> if the standards allow it. Sorry, about my attitude, but I was getting=
> pretty desperate. Thanks for not flaming.
>
> To make it up I will look into updating the man pages ;-)

But the man page ALREADY says this:

=A0 =A0 =A0 =A0*** =A0WARNING =A0*** =A0The locale specified by the environ= ment
affects sort
=A0 =A0 =A0 =A0order. =A0Set LC_ALL=3DC to get the traditional sort order t= hat uses
native
=A0 =A0 =A0 =A0byte values.

What more are you proposing?

I have already written a patc= h. It uses the available "-a" command line option to
=A0"force" traditional (ascii) sorting. Have updated man pages ac= cordingly.

=
What is the be= st way to upload it?

>
> A suggestion. I think that sort should sort text based on the LOCALE o= f
> the file, not the system. Couldn't it detect automatically from th= e text,
> whether it is is dealing with UTF-8 or iso?

Unfortunately, no, this is not possible. =A0You're welcome to try= and
write a patch to prove me wrong, but people have already had years of
experience of using environment variables as the way to tell a program
what encoding an input file uses, precisely because there is no other
obvious way of determining a file's locale.

It is possible= . It's been sometime, since I was parsing unicode, but if I remember co= rrectly,
a unicode char sets bits in its data to specify continuation. This ca= lls for adaptive sorting based on input.
I think Bob already mentioned, that it is not acceptable to do a second pas= s on the input (worst case scenario)
to determine input locale, however, adaptive sorting = should not need to. Unfortunately it is considerable
effort and I would n= eed to know your sorting algo. Since I don't and have much work to do t= his period,
I w= rote the much easier ui patch I talked before.

I find it more elegant and eas= ier than changing the environment. If it is acceptable, let me know how to = upload it.
=A0
--
Eric Blake =A0 eblake redhat com =A0 =A0+1-919-301-3266
Libvirt virtualization library http://libvirt.org


--f46d043c801ef0576e04f677ca7d-- From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 07 14:43:54 2014 Received: (at 17189-done) by debbugs.gnu.org; 7 Apr 2014 18:43:54 +0000 Received: from localhost ([127.0.0.1]:39886 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXEWP-0001Bi-Rp for submit@debbugs.gnu.org; Mon, 07 Apr 2014 14:43:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:14356) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXEWL-0001BV-1U for 17189-done@debbugs.gnu.org; Mon, 07 Apr 2014 14:43:50 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s37IhlfU032101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Apr 2014 14:43:47 -0400 Received: from [10.3.113.181] (ovpn-113-181.phx2.redhat.com [10.3.113.181]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s37IhlAU008899; Mon, 7 Apr 2014 14:43:47 -0400 Message-ID: <5342F1E3.8030901@redhat.com> Date: Mon, 07 Apr 2014 12:43:47 -0600 From: Eric Blake Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nikos Balkanas Subject: Re: bug#17189: Sort bug #2 References: <533FF5CD.60409@redhat.com> <53429EF1.1000704@redhat.com> In-Reply-To: X-Enigmail-Version: 1.6 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SgNCOVoTDOBkc5k9fwDNs1kXH8sUAdKl3" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Spam-Score: -5.3 (-----) X-Debbugs-Envelope-To: 17189-done Cc: 17189-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.3 (-----) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SgNCOVoTDOBkc5k9fwDNs1kXH8sUAdKl3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/07/2014 12:11 PM, Nikos Balkanas wrote: >> >> What more are you proposing? >> >=20 > I have already written a patch. It uses the available "-a" command line= > option to > "force" traditional (ascii) sorting. Have updated man pages accordingl= y. >=20 > What is the best way to upload it? http://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING describes the best way to send a patch. However, I will warn you that we are very reluctant to burn a short option letter if there is not already existing practice of another non-GNU implementation using the same short option letter for the same meaning. Furthermore, I think that: LC_ALL=3DC sort ... is just about as easy to type as: sort --ascii ... and that since the former is standardized by POSIX and already supported by non-GNU sort and in wide use now, while the latter is an extension and not likely to percolate into common use for several years, that it is unlikely that we will take the patch (when two ways exist to do the same thing, we prefer the standardized way over a GNU-specific extension). I can't outright reject your patch without seeing it, but am just trying to warn you that the bar for new features in coreutils is fairly high. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --SgNCOVoTDOBkc5k9fwDNs1kXH8sUAdKl3 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTQvHjAAoJEKeha0olJ0Nq1cwIAINj4CHJmck3A7OYoG1Cc8BY xhxXxXcmjqivz2I3xoIUaUMxu+qtnOPbP15LnWdEFi/gaOE4hhgM4GIX+qnkLrPl XaP43fON6HpAvNFn+Ilv1PfJO/Os+OEUQ66E86A87F77S3h+yLOQhpNI1KovOtMb MZ1WwEXC11GR4SnWuPKA1KKvVjTGgOmHhbx+/KbcgxvVHAQuvOeQ0nOjat48Cit/ OXUvQp2mpne+v0BQv/fS9v5qQRAeuMewHHlof/PrPCbfE6O6akV9E1g3jw4IE6+Y ScCCnTxl8Jt1wyKLSRrB55YZ2b1j9l/7cG8zLlphOSK41R5PZqBL/KMsAUDwjlg= =WAXQ -----END PGP SIGNATURE----- --SgNCOVoTDOBkc5k9fwDNs1kXH8sUAdKl3-- From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 07 15:12:05 2014 Received: (at 17189-done) by debbugs.gnu.org; 7 Apr 2014 19:12:05 +0000 Received: from localhost ([127.0.0.1]:39898 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXExg-0001vM-6n for submit@debbugs.gnu.org; Mon, 07 Apr 2014 15:12:04 -0400 Received: from mail-wi0-f179.google.com ([209.85.212.179]:57299) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXExd-0001v3-UJ for 17189-done@debbugs.gnu.org; Mon, 07 Apr 2014 15:12:02 -0400 Received: by mail-wi0-f179.google.com with SMTP id z2so43741wiv.0 for <17189-done@debbugs.gnu.org>; Mon, 07 Apr 2014 12:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q5mhFW3KjCO0pGQUPPooDLtI/3Vg5W8t83rK0+aJgto=; b=uSLycJo3cmKuoKVF7A6rywACVezg0BhER5IKyCZotc8BrXuVeTjWtgSyZ6P35wjKSw +5i9f0MuIz79jlHwasm9XAdQwzxLI9iC9IrlJ3Yg9BngSYHjH38W8D0vtJp+J9FlRssf QHOwh4TL0rZdKM6KgXSLypFeue90xMFCtGvBZjMccfAndDwdbmQFlMUTpx46P2/BC31L kiCLYb88qgST5FqjIvsTsB7khjS53N2AD18n1HEtSGBCPZZKQSb+zGT3kyrKnMcJPrVd CjRaQTPoAY4WhVHwUwx1kFkK8dF9S6czYRCOiWlCzH/37Sd0zYaHtu+6YnoyqGMzO+eh EDiw== MIME-Version: 1.0 X-Received: by 10.194.242.4 with SMTP id wm4mr438691wjc.88.1396897920781; Mon, 07 Apr 2014 12:12:00 -0700 (PDT) Received: by 10.194.135.202 with HTTP; Mon, 7 Apr 2014 12:12:00 -0700 (PDT) In-Reply-To: <5342F1E3.8030901@redhat.com> References: <533FF5CD.60409@redhat.com> <53429EF1.1000704@redhat.com> <5342F1E3.8030901@redhat.com> Date: Mon, 7 Apr 2014 22:12:00 +0300 Message-ID: Subject: Re: bug#17189: Sort bug #2 From: Nikos Balkanas To: Eric Blake Content-Type: multipart/alternative; boundary=089e01419af65b11b204f678a459 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17189-done Cc: 17189-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --089e01419af65b11b204f678a459 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 7, 2014 at 9:43 PM, Eric Blake wrote: > On 04/07/2014 12:11 PM, Nikos Balkanas wrote: > > >> > >> What more are you proposing? > >> > > > > I have already written a patch. It uses the available "-a" command line > > option to > > "force" traditional (ascii) sorting. Have updated man pages accordingly. > > > > What is the best way to upload it? > > http://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING describes > the best way to send a patch. However, I will warn you that we are very > reluctant to burn a short option letter if there is not already existing > practice of another non-GNU implementation using the same short option > letter for the same meaning. Furthermore, I think that: > > LC_ALL=C sort ... > > is just about as easy to type as: > > sort --ascii ... > > and that since the former is standardized by POSIX and already supported > by non-GNU sort and in wide use now, while the latter is an extension > and not likely to percolate into common use for several years, that it > is unlikely that we will take the patch (when two ways exist to do the > same thing, we prefer the standardized way over a GNU-specific > extension). I can't outright reject your patch without seeing it, but > am just trying to warn you that the bar for new features in coreutils is > fairly high. > > Actually: sort -a is much easier on the eye, and the hand. I don't like the LC_ALL=C. A lot of typos, caps are not easy, environment is best suited for many programs, not single ones. Sort is just one of 1000s of tools a user has to use daily. Consider what would happen if users had to deal with changing the environment in each one of these tools. And more of the same questions from the users. Ultimately you will decide which one creates less questions and support. I owe you a patch, if only for the manpage. It is trivial and don't care if it gets implemented or not. Read HACKING, but wanted to make sure i don't overwrite anything with git. If going through with LC_ALL, then warning should be moved to the top right after the description. The way it is buried now under KEYDEF, noone sees it. Plus adding an example for KEYDEF, which is nearly incomprehensible. Let me know which patch you prefer, so that I can upload (don't want to flood you with patches). > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org > > --089e01419af65b11b204f678a459 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon= , Apr 7, 2014 at 9:43 PM, Eric Blake <eblake@redhat.com> wro= te:
On 04/07/2014 12:11 PM, Niko= s Balkanas wrote:

>>
>> What more are you proposing?
>>
>
> I have already written a patch. It uses the available "-a" c= ommand line
> option to
> =A0"force" traditional (ascii) sorting. Have updated man pag= es accordingly.
>
> What is the best way to upload it?

http://git.savannah.gnu.org/cgit/coreutils.git/tree/HA= CKING describes
the best way to send a patch. =A0However, I will warn you that we are very<= br> reluctant to burn a short option letter if there is not already existing practice of another non-GNU implementation using the same short option
letter for the same meaning. =A0Furthermore, I think that:

LC_ALL=3DC sort ...

is just about as easy to type as:

sort --ascii ...

and that since the former is standardized by POSIX and already supported by non-GNU sort and in wide use now, while the latter is an extension
and not likely to percolate into common use for several years, that it
is unlikely that we will take the patch (when two ways exist to do the
same thing, we prefer the standardized way over a GNU-specific
extension). =A0I can't outright reject your patch without seeing it, bu= t
am just trying to warn you that the bar for new features in coreutils is fairly high.

<= br>
Actually:

sort -a

is much easier on= the eye, and the hand. I don't like the LC_ALL=3DC. A lot of typos, ca= ps are not easy,
environment is best = suited for many programs, not single ones. Sort is just one of 1000s of too= ls a user has to use daily.
Consider what would happen if users had to deal with changing the environme= nt in each one of these tools.
And more of the same questions from the users. Ultimately y= ou will decide which one creates less questions and support.=A0

I owe you a patch, if only for= the manpage. It is trivial and don't care if it gets implemented or no= t. Read HACKING,
but wanted to make s= ure i don't overwrite anything with git. If going through with LC_ALL, = then warning should be moved
to the top right after the description. The way it is buried now under KEYD= EF, noone sees it. Plus adding an
example for KEYDEF, which is nearly incomprehensible.

Let me know which patch you pr= efer, so that I can upload (don't want to flood you with patches).
--
Eric Blake =A0 eblake redhat com =A0 =A0+1-919-301-3266
Libvirt virtualization library http://libvirt.org


--089e01419af65b11b204f678a459-- From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 07 16:43:54 2014 Received: (at 17189-done) by debbugs.gnu.org; 7 Apr 2014 20:43:54 +0000 Received: from localhost ([127.0.0.1]:39916 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXGOX-0004GZ-NE for submit@debbugs.gnu.org; Mon, 07 Apr 2014 16:43:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37479) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXGOT-0004GO-Nq for 17189-done@debbugs.gnu.org; Mon, 07 Apr 2014 16:43:51 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s37KhmcA012021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Apr 2014 16:43:48 -0400 Received: from [10.3.113.181] (ovpn-113-181.phx2.redhat.com [10.3.113.181]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s37KhlZu024411; Mon, 7 Apr 2014 16:43:48 -0400 Message-ID: <53430E03.7080604@redhat.com> Date: Mon, 07 Apr 2014 14:43:47 -0600 From: Eric Blake Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nikos Balkanas Subject: Re: bug#17189: Sort bug #2 References: <533FF5CD.60409@redhat.com> <53429EF1.1000704@redhat.com> <5342F1E3.8030901@redhat.com> In-Reply-To: X-Enigmail-Version: 1.6 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TXnwn0HqdCS1HvWB9msjNOxSJl6uDgXw4" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Spam-Score: -5.3 (-----) X-Debbugs-Envelope-To: 17189-done Cc: 17189-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.3 (-----) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TXnwn0HqdCS1HvWB9msjNOxSJl6uDgXw4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/07/2014 01:12 PM, Nikos Balkanas wrote: >> http://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING describes >> the best way to send a patch. However, I will warn you that we are ve= ry >> reluctant to burn a short option letter if there is not already existi= ng >> practice of another non-GNU implementation using the same short option= >> letter for the same meaning. Furthermore, I think that: >> >> LC_ALL=3DC sort ... >> >> is just about as easy to type as: >> >> sort --ascii ... >> > Actually: >=20 > sort -a >=20 > is much easier on the eye, and the hand. Yes, but it presupposes burning a short option. You'll have more success getting a long option admitted, and only after it has proven useful would a later release then commit to a short option, unless you can first prove that someone else (such as BSD sort) already uses -a for that same purpose. > I don't like the LC_ALL=3DC. A lot > of typos, caps are not easy, > environment is best suited for many programs, not single ones. Ah, but LC_COLLATE and friends DO suit many programs - 'sort', 'ls', shell globs, and many other programs ALL use the SAME environment variable for determining how their use of strcoll() will behave. It does no good to turn a blind eye to the fact that POSIX has already standardized that any program that sorts (and not just 'sort') should pay attention to the user's locale settings, where locale is set by environment variables. >=20 > Let me know which patch you prefer, so that I can upload (don't want to= > flood you with patches). Whatever you're willing to send. This list is fairly low-volume compared to other lists, such as the kernel, so we don't mind seeing your patches, even if we decide not to apply it in entirety. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --TXnwn0HqdCS1HvWB9msjNOxSJl6uDgXw4 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTQw4DAAoJEKeha0olJ0Nqvj0H/ROmGcIiJOBAHVBmjcK5mIl2 u4EUF0dxw5DKW2Kt/pbhC2Y0pGYg+7y0t+uSaw+mQ7rFAsEykfVIsYHtq9cEcDIT Y2VhfgHvuBYwh16jl8bsow2JmCxLlTyTUIERTYt0anMzRBi9SnRBbfZsH7viAg7j b7fGVrEp13VzC5bTT209ShL1ZeUwks+xP5u2IpweSs/kBg2mJ3Cr8iXL1L5Iav8J x+mrkQ+yTIjq1wX4fJH7C3uEjETao0FYCN+FIrzU7YEbFQ+zK4Wm5drV38GG2K/y IjlzM3SjSp/ledPzc8xELpb7O2TkE/bXsWN/ZFvxcyhNEwTP1wI5qGqNJLqRhuc= =5T9j -----END PGP SIGNATURE----- --TXnwn0HqdCS1HvWB9msjNOxSJl6uDgXw4-- From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 07 20:10:51 2014 Received: (at 17189-done) by debbugs.gnu.org; 8 Apr 2014 00:10:52 +0000 Received: from localhost ([127.0.0.1]:40014 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXJco-0002Hx-Li for submit@debbugs.gnu.org; Mon, 07 Apr 2014 20:10:51 -0400 Received: from nm47-vm7.bullet.mail.bf1.yahoo.com ([216.109.115.142]:46916) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXJcl-0002Ho-Rt for 17189-done@debbugs.gnu.org; Mon, 07 Apr 2014 20:10:48 -0400 Received: from [98.139.212.153] by nm47.bullet.mail.bf1.yahoo.com with NNFMP; 08 Apr 2014 00:10:47 -0000 Received: from [98.139.212.207] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 08 Apr 2014 00:10:47 -0000 Received: from [127.0.0.1] by omp1016.mail.bf1.yahoo.com with NNFMP; 08 Apr 2014 00:10:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 569357.37060.bm@omp1016.mail.bf1.yahoo.com Received: (qmail 60079 invoked by uid 60001); 8 Apr 2014 00:10:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1396915847; bh=CaeuyBGzIKWtaYPvn3YAsHD3Av04jJ2WEQgvb7IJ78c=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=TLAyWnkXVmZQhHIPZ3WkW8VaPcX2gzkHwz22NW37nFBccTHSPIxOhCqVCpvK+3sinoALeGYQw6mkj8N5w78BQUbHQ9L6bDyhFEEluDXry3U3eP/LfgFFSIBCYpGlG7BLLNyaBTMObrsnnhJJ7WWrhjFcj0OOcNMEzaBYbCmVEJA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=H0bIw/ZNCU2PV1hFlrWZTif7ijqhZg/9gLCAo3eK0MiIAtnR8w4Zg79iZgQBBar5c+UHqAQpMw3dDoQp/yVZmSf+nmOf0mF1WrLFzP7oX96gagt4YR2qkGG9st0vwsHxXEbfXuXtMV4TJgUzxVfhptkYOVQzwxBcZq4EOj50fXA=; X-YMail-OSG: yY4zyMsVM1lPNExj7GCdAJuomjF5E8qWfHz.tN7H_eMg_Gz d9fLI0llFNQDs1YWYf1WsmYZp_sfq0DIzProOU3bAKLRv3XOBgR3rtLTaNNF nxqmcprWvHJGV7XzqoqEzmrZzfc3uEL91uEnZf7bKq.qiMc.I6EP0pm2NhXe C0lDlD6xLc8Ktxguae8o3fNZSxyVBWy4FBt.K.Yif1LuoUcF9ezmHgdpJpC5 MgTCykzc3L6fSZx8rE3390G7Kn_pXFk7.I8Z5mHcJhlBHl7o2o8Vs89s1k7B tYD6KipYdt2_LMNkHFVr3MjhVD4.U7N3JFcAA4W_yKnBOlpSv9vWVN7iaPMB JSPUosGMj_Rpxx9whx70fPf3tlTcchPiiJKoDJVtohKiHq5VdsKzWJVvASxX 33SiiMQHpppVGLxXqpzMibQs.BUakIZNIx3Dox.59c7AShS_9N.cXjnuv59c mYhtivp617Hyq5sx9onKT828FbbKKbJYLkvzrgwmpA9nl9kXr0AxY4LPSvOU vfyHUXRtqdOILnY0oFoIlMpz.HRs9y0FFBY3h9IN.FIq6HaLrky_NdcwU2NG 3KsFUVKxCwbjbhBqUyZq9M9MSU6y70t9_84YjYfHh Received: from [70.49.120.43] by web142604.mail.bf1.yahoo.com via HTTP; Mon, 07 Apr 2014 17:10:47 PDT X-Rocket-MIMEInfo: 002.001, V2l0aCB0aGUgcGF0Y2gsIHdoYXQgZG9lcyB0aGUgc29ydCBkbyBmb3Igbm9uLWFzY2lpIGlucHV0LsKgIFdoYXQgYWJvdXQgYSBiaW5hcnkgc29ydCwgd2h5IGlucHV0IGZpZWxkIGJ5dGVzIHJhbmdlIGZyb20gMCB0byB4ZmYgd2hlcmUgdGhlIHl0ZXMgYXJlIHRyZWF0ZWQgYXMgdW5zaWduZWQgKDAuLjI1NSk_wqDCoMKgIAoKwqAKUmVnYXJkcyAKCsKgTGVzbGllCgpNci4gTGVzbGllIFNhdGVuc3RlaW4KU0VOVCBGUk9NIE1ZIE9QRU4gU09VUkNFIExJTlVYIFNZU1RFTS4KCgoKCj5fX19fX19fX19fX19fX18BMAEBAQE- X-Mailer: YahooMailWebService/0.8.182.648 References: <533FF5CD.60409@redhat.com> <53429EF1.1000704@redhat.com> <5342F1E3.8030901@redhat.com> Message-ID: <1396915847.39871.YahooMailNeo@web142604.mail.bf1.yahoo.com> Date: Mon, 7 Apr 2014 17:10:47 -0700 (PDT) From: Leslie S Satenstein Subject: Re: bug#17189: Sort bug #2 To: Eric Blake , Nikos Balkanas In-Reply-To: <5342F1E3.8030901@redhat.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="473635693-882544136-1396915847=:39871" X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: 17189-done Cc: "17189-done@debbugs.gnu.org" <17189-done@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Leslie S Satenstein List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) --473635693-882544136-1396915847=:39871 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable With the patch, what does the sort do for non-ascii input.=A0 What about a = binary sort, why input field bytes range from 0 to xff where the ytes are t= reated as unsigned (0..255)?=A0=A0=A0 =0A=0A=A0=0ARegards =0A=0A=A0Leslie= =0A=0AMr. Leslie Satenstein=0ASENT FROM MY OPEN SOURCE LINUX SYSTEM.=0A=0A= =0A=0A=0A>________________________________=0A> From: Eric Blake =0A>To: Nikos Balkanas =0A>Cc: 17189-done@deb= bugs.gnu.org =0A>Sent: Monday, April 7, 2014 2:43 PM=0A>Subject: bug#17189:= Sort bug #2=0A> =0A>=0A>On 04/07/2014 12:11 PM, Nikos Balkanas wrote:=0A>= =0A>>>=0A>>> What more are you proposing?=0A>>>=0A>> =0A>> I have already w= ritten a patch. It uses the available "-a" command line=0A>> option to=0A>>= =A0 "force" traditional (ascii) sorting. Have updated man pages accordingly= .=0A>> =0A>> What is the best way to upload it?=0A>=0A>http://git.savannah.= gnu.org/cgit/coreutils.git/tree/HACKING describes=0A>the best way to send a= patch.=A0 However, I will warn you that we are very=0A>reluctant to burn a= short option letter if there is not already existing=0A>practice of anothe= r non-GNU implementation using the same short option=0A>letter for the same= meaning.=A0 Furthermore, I think that:=0A>=0A>LC_ALL=3DC sort ...=0A>=0A>i= s just about as easy to type as:=0A>=0A>sort --ascii ...=0A>=0A>and that si= nce the former is standardized by POSIX and already supported=0A>by non-GNU= sort and in wide use now, while the latter is an extension=0A>and not like= ly to percolate into common use for several years, that it=0A>is unlikely t= hat we will take the patch (when two ways exist to do the=0A>same thing, we= prefer the standardized way over a GNU-specific=0A>extension).=A0 I can't = outright reject your patch without seeing it, but=0A>am just trying to warn= you that the bar for new features in coreutils is=0A>fairly high.=0A>=0A>= =0A>-- =0A>Eric Blake=A0 eblake redhat com=A0 =A0 +1-919-301-3266=0A>Libvi= rt virtualization library http://libvirt.org=0A>=0A>=0A> --473635693-882544136-1396915847=:39871 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
With the patch, what does the sort do for non-ascii= input.  What about a binary sort, why input field bytes range from 0 = to xff where the ytes are treated as unsigned (0..255)?    <= br>
 
Regards

 Leslie
Mr. Leslie Satenstein
S= ENT FROM MY OPEN SOURCE LINUX SYSTEM.


From: Eric Blake <eblake@redhat.com>
To: Nikos Balkanas <nbalkanas@gma= il.com>
Cc: 17189-d= one@debbugs.gnu.org
Sent:= Monday, April 7, 2014 2:43 PM
Subject: bug#17189: Sort bug #2

On 04/07/2014 12:11 PM, Nikos Balkanas wrote:=

>>
>> W= hat more are you proposing?
>>
&g= t;
> I have already written a patch. It uses the avai= lable "-a" command line
> option to
= >  "force" traditional (ascii) sorting. Have updated man pages acco= rdingly.
>
> What is the best wa= y to upload it?

http://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING des= cribes
the best way to send a patch.  However, I wil= l warn you that we are very
reluctant to burn a short opt= ion letter if there is not already existing
practice of another non-GNU implementat= ion using the same short option
letter for the same meani= ng.  Furthermore, I think that:

L= C_ALL=3DC sort ...

is just about as ea= sy to type as:

sort --ascii ...

and that since the former is standardized by= POSIX and already supported
by non-GNU sort and in wide = use now, while the latter is an extension
and not likely = to percolate into common use for several years, that it
i= s unlikely that we will take the patch (when two ways exist to do the
same thing, we prefer the standardized way over a GNU-specific=
extension).  I can't outright reject your patch wit= hout seeing it, but
am just trying to warn you that the b= ar for new features in coreutils is
fairly high.


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


--473635693-882544136-1396915847=:39871-- From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 08 23:13:25 2014 Received: (at 17189-done) by debbugs.gnu.org; 9 Apr 2014 03:13:25 +0000 Received: from localhost ([127.0.0.1]:38326 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXix2-0001RD-8v for submit@debbugs.gnu.org; Tue, 08 Apr 2014 23:13:24 -0400 Received: from mail-we0-f174.google.com ([74.125.82.174]:36469) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXiwz-0001Qr-7e for 17189-done@debbugs.gnu.org; Tue, 08 Apr 2014 23:13:22 -0400 Received: by mail-we0-f174.google.com with SMTP id t60so1840919wes.19 for <17189-done@debbugs.gnu.org>; Tue, 08 Apr 2014 20:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/WhAYx1pjX8fyr+eJQH6oz87u5ABT4rRXgaCZujHAzI=; b=mKVsyarPbP3qPggU+OzKIMMg37LghTCRD+Orgnve9N+BI5ojUflbKfnnrhg036HwCt EGK+GQqnQEGE4BibVYb1DVq1++uO4CtrzB7kN0eErWXYaeWKO0nl8siPKpRe+V4vohBn wTGB063W1iv/Yk33slsK8X2vAa7HOZAzn0JHgL12XIKGOGdpCNlpanAEZ/YFUIJJZPGY QmoM3qhCSY4iqXq0by2f/AZy/42BPOS11V+V6QW+0Unds4AqeOBzs08bx/x/pwrQT0A9 B4EErmWA1a9WIOOzQTVKDZ/NAt0LMRsgW8WxTXh79WYJF06bfGLQjFTw9xQ9Zy7fM/EF gg7w== MIME-Version: 1.0 X-Received: by 10.180.12.14 with SMTP id u14mr35050057wib.0.1397013195391; Tue, 08 Apr 2014 20:13:15 -0700 (PDT) Received: by 10.194.135.202 with HTTP; Tue, 8 Apr 2014 20:13:15 -0700 (PDT) In-Reply-To: <1396915847.39871.YahooMailNeo@web142604.mail.bf1.yahoo.com> References: <533FF5CD.60409@redhat.com> <53429EF1.1000704@redhat.com> <5342F1E3.8030901@redhat.com> <1396915847.39871.YahooMailNeo@web142604.mail.bf1.yahoo.com> Date: Wed, 9 Apr 2014 06:13:15 +0300 Message-ID: Subject: Re: bug#17189: Sort bug #2 From: Nikos Balkanas To: Leslie S Satenstein Content-Type: multipart/alternative; boundary=001a11c23ed242071804f6937b34 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17189-done Cc: Eric Blake , "17189-done@debbugs.gnu.org" <17189-done@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a11c23ed242071804f6937b34 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 8, 2014 at 3:10 AM, Leslie S Satenstein wrote: > With the patch, what does the sort do for non-ascii input. What about a > binary sort, why input field bytes range from 0 to xff where the ytes are > treated as unsigned (0..255)? > > Regards > > The proposed patch doesn't affect at all sorting behavior. It is an optional parameter, that the user can use to set the environment to ASCII, which means strict byte ordering. I imagine that's what you would want with 8-bit input. I would hate to leave such input to a unicode locale, such as is the default to current OSs. Nikos > * Leslie* > *Mr. Leslie Satenstein* > *SENT FROM MY OPEN SOURCE LINUX SYSTEM.* > > > ------------------------------ > *From:* Eric Blake > *To:* Nikos Balkanas > *Cc:* 17189-done@debbugs.gnu.org > *Sent:* Monday, April 7, 2014 2:43 PM > *Subject:* bug#17189: Sort bug #2 > > On 04/07/2014 12:11 PM, Nikos Balkanas wrote: > > >> > >> What more are you proposing? > >> > > > > I have already written a patch. It uses the available "-a" command line > > option to > > "force" traditional (ascii) sorting. Have updated man pages accordingly. > > > > What is the best way to upload it? > > http://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING describes > the best way to send a patch. However, I will warn you that we are very > reluctant to burn a short option letter if there is not already existing > practice of another non-GNU implementation using the same short option > letter for the same meaning. Furthermore, I think that: > > LC_ALL=C sort ... > > is just about as easy to type as: > > sort --ascii ... > > and that since the former is standardized by POSIX and already supported > by non-GNU sort and in wide use now, while the latter is an extension > and not likely to percolate into common use for several years, that it > is unlikely that we will take the patch (when two ways exist to do the > same thing, we prefer the standardized way over a GNU-specific > extension). I can't outright reject your patch without seeing it, but > am just trying to warn you that the bar for new features in coreutils is > fairly high. > > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org > > > --001a11c23ed242071804f6937b34 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --001a11c23ed242071804f6937b34-- From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 09 04:57:29 2014 Received: (at 17189-done) by debbugs.gnu.org; 9 Apr 2014 08:57:29 +0000 Received: from localhost ([127.0.0.1]:38440 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXoK0-00025A-3B for submit@debbugs.gnu.org; Wed, 09 Apr 2014 04:57:28 -0400 Received: from mail-wi0-f172.google.com ([209.85.212.172]:64866) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXoJv-00024u-UF for 17189-done@debbugs.gnu.org; Wed, 09 Apr 2014 04:57:25 -0400 Received: by mail-wi0-f172.google.com with SMTP id hi2so8465016wib.5 for <17189-done@debbugs.gnu.org>; Wed, 09 Apr 2014 01:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gYUrWtK0B6v5PiP7wZuooaViDu9CvzQkpRBG+WLWulU=; b=a32/HtHvB5luQ1C1XShkrO7JlSGzIjTGilupgJqD2S9EM9uaQIcc8XdVODZxgSysw2 loHr3Tyvbs2kTLy3X6oOq390MRMgIZcp8wRDhGp+arRmMJ4Aor8tV6QpIlDSk9NpAjNp C2v/2xMz+VwPPNDOudoVGjEN3seC4vt0Y047B2Pls+eAnaTfCXI206sjsXy2h/hk5xd5 8Vxwm5DBm4Omd/niss1DGRUYMfmEswbRC1d968+7E6A6P9+58LMhb89Ku5yaCDz3yfvC GKRH3DDk6Rq/Ye6al5syLK+nuqP8S0N8bV0/lOtwhTOG5X+0fS6HS+zsO9SHuuOmQStd jvXQ== MIME-Version: 1.0 X-Received: by 10.194.190.42 with SMTP id gn10mr8530675wjc.9.1397033837939; Wed, 09 Apr 2014 01:57:17 -0700 (PDT) Received: by 10.194.135.202 with HTTP; Wed, 9 Apr 2014 01:57:17 -0700 (PDT) In-Reply-To: <53430E03.7080604@redhat.com> References: <533FF5CD.60409@redhat.com> <53429EF1.1000704@redhat.com> <5342F1E3.8030901@redhat.com> <53430E03.7080604@redhat.com> Date: Wed, 9 Apr 2014 11:57:17 +0300 Message-ID: Subject: Re: bug#17189: Sort bug #2 From: Nikos Balkanas To: Eric Blake Content-Type: multipart/mixed; boundary=047d7bb70882a662c304f69849a9 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17189-done Cc: 17189-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --047d7bb70882a662c304f69849a9 Content-Type: multipart/alternative; boundary=047d7bb70882a662bd04f69849a7 --047d7bb70882a662bd04f69849a7 Content-Type: text/plain; charset=ISO-8859-1 [..snip..] Whatever you're willing to send. This list is fairly low-volume > compared to other lists, such as the kernel, so we don't mind seeing > your patches, even if we decide not to apply it in entirety. > > Hi Eric, Here are both the patches, ascii-sort.diff and man-sort.diff. Sorry, couldn't get git to produce the correct output, according to the "HACKING" instructions (it listed 3 differenet files from the commit, but no sort.c among them) so I am sending them the traditional way. I am no git guru, and can't loose more time over git. The ascii patch introduces the -a, --ascii option and modifies the man page, while the man patch moves the warning to the top, under the Description and adds a couple of examples of using sort. That's the best I can do. Do as you wish with them. BR, Nikos > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org > > --047d7bb70882a662bd04f69849a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

[..snip..]



Whatever you're willing to send. =A0This= list is fairly low-volume
compared to other lists, such as the kernel, so we don't mind seeing your patches, even if we decide not to apply it in entirety.

<= br>
Hi Eric,

Here are both the patches, ascii-sort.diff and man-sort.diff. Sorry, couldn= 't get git to produce the correct output, according
to the "HACKING" instruc= tions (it listed 3 differenet files from the commit, but no sort.c among th= em) so I am sending them
the traditional way.= I am no git guru, and can't loose more time over git. The ascii patch = introduces the -a, --ascii option
and modifies the man page, while the man patch moves the warning to the top= , under the Description and adds a couple of
examples of using sort.

That's= the best I can do. Do as you wish with them.

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


--047d7bb70882a662bd04f69849a7-- --047d7bb70882a662c304f69849a9 Content-Type: application/x-gzip; name="sort_patch.tgz" Content-Disposition: attachment; filename="sort_patch.tgz" Content-Transfer-Encoding: base64 X-Attachment-Id: f_htsdsgk51 H4sIAHEHRVMAA+2V30/bMBDH+9y/4tQXfiip8rOFUJAQYhNSxwOw8bBOyE2c1mpqV7bTjU3733eu O9R1HSChDiH58xAn8flyvpzvS1TOmK+E1O2ClWVjGwRIJ0nMGHbTYHU0hEkSN8IojsLITESNIIyD IG1AsJVo1qiVJhKgwdlEqEfsnpp/oyTxQZHE3WYPAHzige8TUxGwTq0o2JlK5KSisKslKZhmgpMK TP0wPtob8EEzjUIvjZI8jQL0qscUKNdMUqgYNz4Wryb0vg2MZmZBD+zVOAF/ErZD8DUMBhoYn9Ua TkDUGm/QShq7a2OnyRAUnRFJNC2WhiTPhSwwDtACSiaVhlxU9ZQD4QV8lUxTYNpMWodt813f95sn j4W52FMckTQ69HBE4/39fbg9vbq8uHxv7o3BCdyg+TI1akZzVjKMa3i/9DxnUvApfgFIWdJcK7tb DJfKtnVwTTX0z+5O+/3jMxPjCJ/N4vU820U4RbT5K8qu5kSzOcUP4h7npKqpsoGn+CPSxGRXo0UO +RirPRccc6PG6O1OzIxv9fkLHEPLJ8P8rChHYzbJph+4yOSVus50dpPVn+6z762jZbqe5+wpX2l6 UKSprb0frUV1tTzg4o7IUW2S5cHlx37fgx2y89NrJmHQ8fCCBRsGyWKVJSdYnGiTrbwDrA5t/8eu zaoHrbPW3tEfNkNJyeSomcSdDp6CTrjR6Wsf0a0yJXzL3f/p/p8GD/0/jjtoF0ZJN3b9/3+QRAde Eic5jlj8t4seaeoBmxce7By7q+ksgoMogVQVvLvon++qPdOgMHG8ILJY6aaL/ryhPfZe2h57L2qP vU3tEc6/Zb9DfnBsNciqj1//Q4Bu/lY+kx6UJH9dkh60xgNJp2JuTIt6NquYSa1aUaCXph51t4O6 e/gM3bUb36S7jwiundqqxnbfpsa+9hF2OBwOh8PhcDgcDofD4XA4HA6Hw+FwOByOBb8AZEVRTgAo AAA= --047d7bb70882a662c304f69849a9-- From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 09 08:55:00 2014 Received: (at 17189-done) by debbugs.gnu.org; 9 Apr 2014 12:55:00 +0000 Received: from localhost ([127.0.0.1]:38592 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXs1r-000199-2q for submit@debbugs.gnu.org; Wed, 09 Apr 2014 08:54:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47010) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXs1n-00018y-Uy for 17189-done@debbugs.gnu.org; Wed, 09 Apr 2014 08:54:57 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s39Csr0N021826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Apr 2014 08:54:53 -0400 Received: from [10.3.113.140] (ovpn-113-140.phx2.redhat.com [10.3.113.140]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s39CsrkE006786; Wed, 9 Apr 2014 08:54:53 -0400 Message-ID: <5345431C.4090208@redhat.com> Date: Wed, 09 Apr 2014 06:54:52 -0600 From: Eric Blake Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nikos Balkanas Subject: Re: bug#17189: Sort bug #2 References: <533FF5CD.60409@redhat.com> <53429EF1.1000704@redhat.com> <5342F1E3.8030901@redhat.com> <53430E03.7080604@redhat.com> In-Reply-To: X-Enigmail-Version: 1.6 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="aWqBudPhMhASgvsbiaPgCnS8bi98ot37a" X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-Spam-Score: -5.3 (-----) X-Debbugs-Envelope-To: 17189-done Cc: 17189-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.3 (-----) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aWqBudPhMhASgvsbiaPgCnS8bi98ot37a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/09/2014 02:57 AM, Nikos Balkanas wrote: >=20 > Here are both the patches, ascii-sort.diff and man-sort.diff. Sorry, > couldn't get git to produce the correct output, according > to the "HACKING" instructions (it listed 3 differenet files from the > commit, but no sort.c among them) so I am sending them > the traditional way. I am no git guru, and can't loose more time over g= it. I'm sorry you feel that way, but sending patches as a .tgz file instead of directly inline means more work for the maintainer. We can help you figure out the correct git instructions, and doing so will help you on your contributions to future projects. Following a project's preferred submission policies shows that you have initiative and gives your patches more clout; failing to do so makes your patches that much harder to read and that much less likely to be applied. As is, your patches are COMPLETELY broken. You sent them in 'ed' format, but we REQUIRE patches to be in unified [diff -u] format (or at a minimum, context [diff -c] format); git defaults to unified format for a reason. 'ed' format is useless because it lacks metadata about the patch, and without that context, it is more likely to be misapplied or fail to apply, particularly if the recipient starts from a different version of the file than the sender. $ patch < ./man-sort.diff patch: **** Only garbage was found in the patch input. We can't work with a patch if we can't even apply it. Since YOU have the correct starting point, the best way is to apply your 'ed' patches with 'patch', then do 'git commit -a' to commit them to your git repository, then 'git format-patch --stdout -1' to produce the patch in the format that we can read. Bonus points if you use 'git send-email -1' instead of 'git format-patch', although getting 'git send-email' set up to work correctly takes more work on your side. > The ascii patch introduces the -a, --ascii option How many times do I have to repeat myself? Can you point to prior art for '-a' meaning to enforce 'LC_ALL=3DC' collation in any other sort implementation? If not, then I prefer that the initial version only supply the long option. Furthermore, I am 90-10 against including any new --ascii option, as LC_ALL=3DC is already the standardized method for achieving the same effect. > and modifies the man page, while the man patch moves the warning to the= > top, under the Description and adds a couple of > examples of using sort. Moving the blurb may indeed make sense; but I can't see where you are proposing to move it, because your patch was broken. Would you mind resubmitting, please? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --aWqBudPhMhASgvsbiaPgCnS8bi98ot37a 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTRUMdAAoJEKeha0olJ0Nq46IIAIWGDusENLHSzZxD3iMqMcJa Cnbmy0g5swZm+Rxj3lXwpd8CkeGbbqS+gKG7J5UuCqBQXfoKJxq+7RvozEyrjLZJ OBqbKU7WWlv5cjW3+rLGc5PHAHiMOKjg2pK3fr7REtFBERGqIqZpcZlFxYz2OnG3 hPaz2wHaLM8dMumtpDjViuhms6tMRUVLrNdaOHX0uzv3FXmYUd1AGEG4+fR9BrXy MUaLTLQVx10O3Vs/mdBSnW4frXCzDPMOhQIC1D62aNsyrRLRI8YlvjoDQzPK15h6 G+Ca4XD4CUJTw6Xvuj9DNDJGG8jABGnS/dKcbduszlYsB6Q68iysvmyskeHrzYk= =Hi14 -----END PGP SIGNATURE----- --aWqBudPhMhASgvsbiaPgCnS8bi98ot37a-- From unknown Mon Jun 23 07:51:24 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 08 May 2014 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator


On Tue= , Apr 8, 2014 at 3:10 AM, Leslie S Satenstein <lsatenstein@yahoo.com> wrote:
With the patch, what does the sort do for non-ascii input.=A0 What ab= out a binary sort, why input field bytes range from 0 to xff where the ytes= are treated as unsigned (0..255)?=A0=A0=A0
=A0
=
Regards


The proposed patch doesn't affect at all sorting behavior. It is an opt= ional parameter, that the user can use to set the environment to ASCII, whi= ch means strict
byte ordering. I imagine that's what you would want with 8-bit input. I= would hate to leave such input to a unicode locale, such as is the default= to current OSs.

Nikos

=A0Leslie
Mr. Leslie Satenstein
SENT FROM MY OPEN SOURCE LINUX SYSTEM.

From: Eric Blake <eblake@redhat.com>
To: Nikos Balkanas <nbalkanas@gmail.com>
Cc: 17189-done@debbugs.gnu.org
= Sent: Monday, April 7, 2014= 2:43 PM
Subject: bug#17189: Sort bu= g #2

On 04/07/2014 12:11= PM, Nikos Balkanas wrote:

>> >> What more are you proposing?
>>
>
> I have already written a patch. It u= ses the available "-a" command line
> option= to
>=A0 "force" traditional (ascii) sorting. Have updated man pag= es accordingly.
>
> What is the = best way to upload it?

http://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING = describes
the best way to send a patch.=A0 However, I will warn you that we are very<= br clear=3D"none">reluctant to burn a short option letter if there is not already existing
practice of another non-GNU implementat= ion using the same short option
letter for the same meani= ng.=A0 Furthermore, I think that:

LC_A= LL=3DC sort ...

is just about as easy to type as:

sort --ascii ...

and th= at since the former is standardized by POSIX and already supported
by non-GNU sort and in wide use now, while the latter is an extension
and not likely to percolate into common use for several years,= that it
is unlikely that we will take the patch (when tw= o ways exist to do the
same thing, we prefer the standardized way over a GNU-specific
extension).=A0 I can't outright reject your patch without seeing = it, but
am just trying to warn you that the bar for new f= eatures in coreutils is
fairly high.


--
Eric Blake=A0 eblake redhat com=A0 =A0 <= a href=3D"tel:%2B1-919-301-3266" value=3D"+19193013266" target=3D"_blank">+= 1-919-301-3266
Libvirt virtualization library http://libvirt.org

=