From unknown Mon Jun 23 04:14:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17188: Sort bugs Resent-From: Nikos Balkanas Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Sat, 05 Apr 2014 02:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 17188 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: 17188@debbugs.gnu.org X-Debbugs-Original-To: bug-coreutils@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.139666476726713 (code B ref -1); Sat, 05 Apr 2014 02:27:02 +0000 Received: (at submit) by debbugs.gnu.org; 5 Apr 2014 02:26:07 +0000 Received: from localhost ([127.0.0.1]:35796 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWGJ4-0006wm-88 for submit@debbugs.gnu.org; Fri, 04 Apr 2014 22:26:06 -0400 Received: from eggs.gnu.org ([208.118.235.92]:49385) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWG0h-0006PH-By for submit@debbugs.gnu.org; Fri, 04 Apr 2014 22:07:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WWG0g-0000tw-Co for submit@debbugs.gnu.org; Fri, 04 Apr 2014 22:07:07 -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.0 required=5.0 tests=BAYES_20,FREEMAIL_FROM, HTML_MESSAGE,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:33155) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WWG0g-0000ts-9o for submit@debbugs.gnu.org; Fri, 04 Apr 2014 22:07:06 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51107) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WWG0f-00029P-FO for bug-coreutils@gnu.org; Fri, 04 Apr 2014 22:07:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WWG0e-0000ti-PY for bug-coreutils@gnu.org; Fri, 04 Apr 2014 22:07:05 -0400 Received: from mail-wg0-x22f.google.com ([2a00:1450:400c:c00::22f]:51520) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WWG0e-0000te-IC for bug-coreutils@gnu.org; Fri, 04 Apr 2014 22:07:04 -0400 Received: by mail-wg0-f47.google.com with SMTP id x12so4177373wgg.18 for ; Fri, 04 Apr 2014 19:07:02 -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=AAhHX/9nLMM51nlJtOsBrCdbvQUzUFyaT+fLpO+zgzE=; b=dDZIIr5vrt152u+NWpeE4OlHzOm5JZHP+WYbK+MTniusmtv/pPgASj5EFLEK/qv5S9 BuoaTLwi7sCr6rSyOggMZZFRbMSzZp7IVdZswMxUgSykxvdB4V+H3AG+3h5fZyBJ3f34 N4QpMnG3vVI1VX4A7UdjwrircHw9wBflRSXsr96DKBlwZ4YffgkNd2IMgf/POEoVWd82 qoSvOmtawSZ4lZMe/eYFCCPlmm0IBypa7A0V0bB6XX9ryBhq/E1BP81RpFsEC2U7Ke6C HxGyOi/JP4ULFEUVo1cW3USO2LbtjwAQTOfs+PVcdGHhcfau/nmydEci1pS+UqXzjLBW wWCw== MIME-Version: 1.0 X-Received: by 10.180.12.147 with SMTP id y19mr8532373wib.39.1396663622408; Fri, 04 Apr 2014 19:07:02 -0700 (PDT) Received: by 10.194.165.65 with HTTP; Fri, 4 Apr 2014 19:07:02 -0700 (PDT) Date: Sat, 5 Apr 2014 05:07:02 +0300 Message-ID: From: Nikos Balkanas Content-Type: multipart/alternative; boundary=001a11c21ba615a11c04f642173f 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-Mailman-Approved-At: Fri, 04 Apr 2014 22:26:05 -0400 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 (----) --001a11c21ba615a11c04f642173f Content-Type: text/plain; charset=ISO-8859-1 Hi, Sort is seriously bugged. This is the output from: sort -d -t \t -k1 input > out 0009rN2S3cohd2DGH6yuTWBoeuq6DwWZhCBDEnFzYqpw984FfALy7NUhEZH1.YEbiq/ 000EMQeKUjtyXIOaUkT.XE6SaBIdOqTA0nffF394V6tkcVdup2c3ihi7yhbuRof2Y5agTG 000p8kXIz5Tc1GaxYYXjAfgm7YJOZvyBJxVXMi0lhaJXT22IdDbE6vVhWXW9FkRBxQ 00/0QwzaXrqGHXW7mE9Le8IIVgHoZvccgGydKdzJgh8.SZenbULmIWMtrGShz24W7T 000R2cnZ8.khe1eXDERclkbXASRQeKvcNBaCJRLX617Xvmff0KaoZSSFBNhNG1OiIyr Shouldn't 00/0 be first according to Ascii code? Plz fix. TIA, Nikos --001a11c21ba615a11c04f642173f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,=

=
Sort is seriously bu= gged. This is the output from:

sort -d -t \t -k1 input > o= ut

0009rN2S3cohd2DGH6yuTWBoeuq6DwWZhCBDEnFzYqpw984FfALy7NUhEZH1.YEbiq/
000E= MQeKUjtyXIOaUkT.XE6SaBIdOqTA0nffF394V6tkcVdup2c3ihi7yhbuRof2Y5agTG
000p8= kXIz5Tc1GaxYYXjAfgm7YJOZvyBJxVXMi0lhaJXT22IdDbE6vVhWXW9FkRBxQ
00/0QwzaXr= qGHXW7mE9Le8IIVgHoZvccgGydKdzJgh8.SZenbULmIWMtrGShz24W7T
000R2cnZ8.khe1eXDERclkbXASRQeKvcNBaCJRLX617Xvmff0KaoZSSFBNhNG1OiIyr

Shouldn't 00/0 be first ac= cording to Ascii code?

Plz fix.

TIA,
Nikos

--001a11c21ba615a11c04f642173f-- From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 05 08:21:39 2014 Received: (at control) by debbugs.gnu.org; 5 Apr 2014 12:21:39 +0000 Received: from localhost ([127.0.0.1]:36061 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWPbO-0007jC-OC for submit@debbugs.gnu.org; Sat, 05 Apr 2014 08:21:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63475) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWPbL-0007it-2F; Sat, 05 Apr 2014 08:21:37 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s35CLXId019757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 Apr 2014 08:21:34 -0400 Received: from [10.3.113.163] (ovpn-113-163.phx2.redhat.com [10.3.113.163]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s35CLXhW023198; Sat, 5 Apr 2014 08:21:33 -0400 Message-ID: <533FF54D.5030404@redhat.com> Date: Sat, 05 Apr 2014 06:21:33 -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 , 17188-done@debbugs.gnu.org Subject: Re: bug#17188: Sort bugs 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="Acc8tQTxl9UluT0Tq1fjCOewgmrvWTwcp" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 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) --Acc8tQTxl9UluT0Tq1fjCOewgmrvWTwcp Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable tag 17188 notabug thanks On 04/04/2014 08:07 PM, Nikos Balkanas wrote: > Hi, >=20 > Sort is seriously bugged. This is the output from: >=20 > sort -d -t \t -k1 input > out -d says to do a dictionary sort that ignores non-alphanumeric characters. But it still leaves it up to your current locale on whether those non-alpha characters are collated case-insensitively. Also, '-k1' is almost always wrong - you generally want '-k1,1' if you want to sort by JUST the first field, rather than by the whole line. See the FAQ: https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Sort-does-n= ot-sort-in-normal-order_0021 >=20 > 0009rN2S3cohd2DGH6yuTWBoeuq6DwWZhCBDEnFzYqpw984FfALy7NUhEZH1.YEbiq/ > 000EMQeKUjtyXIOaUkT.XE6SaBIdOqTA0nffF394V6tkcVdup2c3ihi7yhbuRof2Y5agTG > 000p8kXIz5Tc1GaxYYXjAfgm7YJOZvyBJxVXMi0lhaJXT22IdDbE6vVhWXW9FkRBxQ > 00/0QwzaXrqGHXW7mE9Le8IIVgHoZvccgGydKdzJgh8.SZenbULmIWMtrGShz24W7T > 000R2cnZ8.khe1eXDERclkbXASRQeKvcNBaCJRLX617Xvmff0KaoZSSFBNhNG1OiIyr >=20 > Shouldn't 00/0 be first according to Ascii code? Only if you are asking for a full ASCII sort. Here, I'm adding -s for fewer lines, but using --debug can sometimes help show you where you are asking sort to do something different than you expected, but where sort is behaving correctly given what you asked it to do. I'm guessing your default locale is en_US.UTF-8 - because I get the same results as you in that mode: $ sort --debug -s -d -t \t -k1 input sort: using =E2=80=98en_US.UTF-8=E2=80=99 sorting rules 0009rN2S3cohd2DGH6yuTWBoeuq6DwWZhCBDEnFzYqpw984FfALy7NUhEZH1.YEbiq/ ___________________________________________________________________ 000EMQeKUjtyXIOaUkT.XE6SaBIdOqTA0nffF394V6tkcVdup2c3ihi7yhbuRof2Y5agTG ______________________________________________________________________ 000p8kXIz5Tc1GaxYYXjAfgm7YJOZvyBJxVXMi0lhaJXT22IdDbE6vVhWXW9FkRBxQ __________________________________________________________________ 00/0QwzaXrqGHXW7mE9Le8IIVgHoZvccgGydKdzJgh8.SZenbULmIWMtrGShz24W7T __________________________________________________________________ 000R2cnZ8.khe1eXDERclkbXASRQeKvcNBaCJRLX617Xvmff0KaoZSSFBNhNG1OiIyr ___________________________________________________________________ In this mode, '000p' collates case-insensitively before '000Q', so the sort is correct (the collation was on '000Q' and not '00/0Q' because you used -d). Furthermore, if you omit -d: $ sort --debug -s -t \t -k1 input sort: using =E2=80=98en_US.UTF-8=E2=80=99 sorting rules 0009rN2S3cohd2DGH6yuTWBoeuq6DwWZhCBDEnFzYqpw984FfALy7NUhEZH1.YEbiq/ ___________________________________________________________________ 000EMQeKUjtyXIOaUkT.XE6SaBIdOqTA0nffF394V6tkcVdup2c3ihi7yhbuRof2Y5agTG ______________________________________________________________________ 000p8kXIz5Tc1GaxYYXjAfgm7YJOZvyBJxVXMi0lhaJXT22IdDbE6vVhWXW9FkRBxQ __________________________________________________________________ 00/0QwzaXrqGHXW7mE9Le8IIVgHoZvccgGydKdzJgh8.SZenbULmIWMtrGShz24W7T __________________________________________________________________ 000R2cnZ8.khe1eXDERclkbXASRQeKvcNBaCJRLX617Xvmff0KaoZSSFBNhNG1OiIyr ___________________________________________________________________ No change, because the en_US.UTF-8 locale implicitly does a dictionary collation even without you requesting -d. Now, compare to the C locale, which forces sorting by byte value for more traditional ASCII sorting: $ LC_ALL=3DC sort --debug -s -d -t \t -k1 input sort: using simple byte comparison 0009rN2S3cohd2DGH6yuTWBoeuq6DwWZhCBDEnFzYqpw984FfALy7NUhEZH1.YEbiq/ ___________________________________________________________________ 000EMQeKUjtyXIOaUkT.XE6SaBIdOqTA0nffF394V6tkcVdup2c3ihi7yhbuRof2Y5agTG ______________________________________________________________________ 00/0QwzaXrqGHXW7mE9Le8IIVgHoZvccgGydKdzJgh8.SZenbULmIWMtrGShz24W7T __________________________________________________________________ 000R2cnZ8.khe1eXDERclkbXASRQeKvcNBaCJRLX617Xvmff0KaoZSSFBNhNG1OiIyr ___________________________________________________________________ 000p8kXIz5Tc1GaxYYXjAfgm7YJOZvyBJxVXMi0lhaJXT22IdDbE6vVhWXW9FkRBxQ __________________________________________________________________ '000Q' now sorts before '000R' which sorts before '000p' as expected. And toss out the -d, and you get: $ LC_ALL=3DC sort --debug -s -t \t -k1 input sort: using simple byte comparison 00/0QwzaXrqGHXW7mE9Le8IIVgHoZvccgGydKdzJgh8.SZenbULmIWMtrGShz24W7T __________________________________________________________________ 0009rN2S3cohd2DGH6yuTWBoeuq6DwWZhCBDEnFzYqpw984FfALy7NUhEZH1.YEbiq/ ___________________________________________________________________ 000EMQeKUjtyXIOaUkT.XE6SaBIdOqTA0nffF394V6tkcVdup2c3ihi7yhbuRof2Y5agTG ______________________________________________________________________ 000R2cnZ8.khe1eXDERclkbXASRQeKvcNBaCJRLX617Xvmff0KaoZSSFBNhNG1OiIyr ___________________________________________________________________ 000p8kXIz5Tc1GaxYYXjAfgm7YJOZvyBJxVXMi0lhaJXT22IdDbE6vVhWXW9FkRBxQ __________________________________________________________________ Now '00/' sorts before '000'. It might be a nice improvement to the --debug output to avoid putting _ under any character that sort ignored due to -d before calling strcoll() (which would help the output of the LC_ALL=3DC case, but not the en_US.UTF-8 case) - but that's probably difficult to implement. >=20 > Plz fix. There's nothing to fix but your usage pattern. So I'm closing this as not a bug. But feel free to reply further if you still have questions. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --Acc8tQTxl9UluT0Tq1fjCOewgmrvWTwcp 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/VNAAoJEKeha0olJ0NqYrkH/05+9KkJfn2EsyUBhdvQELuu MzPdJZmYsZC3suU2hyMhz19d7W/xcHxnvHq6FUPS5jfA2ZUyLeVYCxRMKc791BkT XCbRmYvr0lnXbomUXGspJFTRtXx3fTkodr7ZL1mvIE8cOhFBjqRnLZNZZ5/GzSND Q30AOv9+dM3mflhgl5zpGUeTPTvldl69YKXgYojNqsl/cbn75EmKrHCZOqps7Jqu fPdcyDqZZvn/NRaRzv4VV+aFD/2vW8BeBdCXd8L1mKrVdqL9oTJyuAbPUZBy/LlV PgC4do0CZQwamQ98DdP9hnTVcPAIhcYDJRjKNQN1s0jofHBGvS8gbmxJx8YWKjU= =OJ8G -----END PGP SIGNATURE----- --Acc8tQTxl9UluT0Tq1fjCOewgmrvWTwcp-- From unknown Mon Jun 23 04:14:50 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Nikos Balkanas Subject: bug#17188: closed (Re: bug#17188: Sort bugs) Message-ID: References: <533FF54D.5030404@redhat.com> X-Gnu-PR-Message: they-closed 17188 X-Gnu-PR-Package: coreutils X-Gnu-PR-Keywords: notabug Reply-To: 17188@debbugs.gnu.org Date: Sat, 05 Apr 2014 12:22:04 +0000 Content-Type: multipart/mixed; boundary="----------=_1396700524-29798-1" This is a multi-part message in MIME format... ------------=_1396700524-29798-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #17188: Sort bugs which was filed against the coreutils package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 17188@debbugs.gnu.org. --=20 17188: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D17188 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1396700524-29798-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 17188-done) by debbugs.gnu.org; 5 Apr 2014 12:21:38 +0000 Received: from localhost ([127.0.0.1]:36059 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWPbN-0007j7-U9 for submit@debbugs.gnu.org; Sat, 05 Apr 2014 08:21:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63475) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWPbL-0007it-2F; Sat, 05 Apr 2014 08:21:37 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s35CLXId019757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 Apr 2014 08:21:34 -0400 Received: from [10.3.113.163] (ovpn-113-163.phx2.redhat.com [10.3.113.163]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s35CLXhW023198; Sat, 5 Apr 2014 08:21:33 -0400 Message-ID: <533FF54D.5030404@redhat.com> Date: Sat, 05 Apr 2014 06:21:33 -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 , 17188-done@debbugs.gnu.org Subject: Re: bug#17188: Sort bugs 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="Acc8tQTxl9UluT0Tq1fjCOewgmrvWTwcp" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Spam-Score: -5.6 (-----) X-Debbugs-Envelope-To: 17188-done 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) --Acc8tQTxl9UluT0Tq1fjCOewgmrvWTwcp Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable tag 17188 notabug thanks On 04/04/2014 08:07 PM, Nikos Balkanas wrote: > Hi, >=20 > Sort is seriously bugged. This is the output from: >=20 > sort -d -t \t -k1 input > out -d says to do a dictionary sort that ignores non-alphanumeric characters. But it still leaves it up to your current locale on whether those non-alpha characters are collated case-insensitively. Also, '-k1' is almost always wrong - you generally want '-k1,1' if you want to sort by JUST the first field, rather than by the whole line. See the FAQ: https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Sort-does-n= ot-sort-in-normal-order_0021 >=20 > 0009rN2S3cohd2DGH6yuTWBoeuq6DwWZhCBDEnFzYqpw984FfALy7NUhEZH1.YEbiq/ > 000EMQeKUjtyXIOaUkT.XE6SaBIdOqTA0nffF394V6tkcVdup2c3ihi7yhbuRof2Y5agTG > 000p8kXIz5Tc1GaxYYXjAfgm7YJOZvyBJxVXMi0lhaJXT22IdDbE6vVhWXW9FkRBxQ > 00/0QwzaXrqGHXW7mE9Le8IIVgHoZvccgGydKdzJgh8.SZenbULmIWMtrGShz24W7T > 000R2cnZ8.khe1eXDERclkbXASRQeKvcNBaCJRLX617Xvmff0KaoZSSFBNhNG1OiIyr >=20 > Shouldn't 00/0 be first according to Ascii code? Only if you are asking for a full ASCII sort. Here, I'm adding -s for fewer lines, but using --debug can sometimes help show you where you are asking sort to do something different than you expected, but where sort is behaving correctly given what you asked it to do. I'm guessing your default locale is en_US.UTF-8 - because I get the same results as you in that mode: $ sort --debug -s -d -t \t -k1 input sort: using =E2=80=98en_US.UTF-8=E2=80=99 sorting rules 0009rN2S3cohd2DGH6yuTWBoeuq6DwWZhCBDEnFzYqpw984FfALy7NUhEZH1.YEbiq/ ___________________________________________________________________ 000EMQeKUjtyXIOaUkT.XE6SaBIdOqTA0nffF394V6tkcVdup2c3ihi7yhbuRof2Y5agTG ______________________________________________________________________ 000p8kXIz5Tc1GaxYYXjAfgm7YJOZvyBJxVXMi0lhaJXT22IdDbE6vVhWXW9FkRBxQ __________________________________________________________________ 00/0QwzaXrqGHXW7mE9Le8IIVgHoZvccgGydKdzJgh8.SZenbULmIWMtrGShz24W7T __________________________________________________________________ 000R2cnZ8.khe1eXDERclkbXASRQeKvcNBaCJRLX617Xvmff0KaoZSSFBNhNG1OiIyr ___________________________________________________________________ In this mode, '000p' collates case-insensitively before '000Q', so the sort is correct (the collation was on '000Q' and not '00/0Q' because you used -d). Furthermore, if you omit -d: $ sort --debug -s -t \t -k1 input sort: using =E2=80=98en_US.UTF-8=E2=80=99 sorting rules 0009rN2S3cohd2DGH6yuTWBoeuq6DwWZhCBDEnFzYqpw984FfALy7NUhEZH1.YEbiq/ ___________________________________________________________________ 000EMQeKUjtyXIOaUkT.XE6SaBIdOqTA0nffF394V6tkcVdup2c3ihi7yhbuRof2Y5agTG ______________________________________________________________________ 000p8kXIz5Tc1GaxYYXjAfgm7YJOZvyBJxVXMi0lhaJXT22IdDbE6vVhWXW9FkRBxQ __________________________________________________________________ 00/0QwzaXrqGHXW7mE9Le8IIVgHoZvccgGydKdzJgh8.SZenbULmIWMtrGShz24W7T __________________________________________________________________ 000R2cnZ8.khe1eXDERclkbXASRQeKvcNBaCJRLX617Xvmff0KaoZSSFBNhNG1OiIyr ___________________________________________________________________ No change, because the en_US.UTF-8 locale implicitly does a dictionary collation even without you requesting -d. Now, compare to the C locale, which forces sorting by byte value for more traditional ASCII sorting: $ LC_ALL=3DC sort --debug -s -d -t \t -k1 input sort: using simple byte comparison 0009rN2S3cohd2DGH6yuTWBoeuq6DwWZhCBDEnFzYqpw984FfALy7NUhEZH1.YEbiq/ ___________________________________________________________________ 000EMQeKUjtyXIOaUkT.XE6SaBIdOqTA0nffF394V6tkcVdup2c3ihi7yhbuRof2Y5agTG ______________________________________________________________________ 00/0QwzaXrqGHXW7mE9Le8IIVgHoZvccgGydKdzJgh8.SZenbULmIWMtrGShz24W7T __________________________________________________________________ 000R2cnZ8.khe1eXDERclkbXASRQeKvcNBaCJRLX617Xvmff0KaoZSSFBNhNG1OiIyr ___________________________________________________________________ 000p8kXIz5Tc1GaxYYXjAfgm7YJOZvyBJxVXMi0lhaJXT22IdDbE6vVhWXW9FkRBxQ __________________________________________________________________ '000Q' now sorts before '000R' which sorts before '000p' as expected. And toss out the -d, and you get: $ LC_ALL=3DC sort --debug -s -t \t -k1 input sort: using simple byte comparison 00/0QwzaXrqGHXW7mE9Le8IIVgHoZvccgGydKdzJgh8.SZenbULmIWMtrGShz24W7T __________________________________________________________________ 0009rN2S3cohd2DGH6yuTWBoeuq6DwWZhCBDEnFzYqpw984FfALy7NUhEZH1.YEbiq/ ___________________________________________________________________ 000EMQeKUjtyXIOaUkT.XE6SaBIdOqTA0nffF394V6tkcVdup2c3ihi7yhbuRof2Y5agTG ______________________________________________________________________ 000R2cnZ8.khe1eXDERclkbXASRQeKvcNBaCJRLX617Xvmff0KaoZSSFBNhNG1OiIyr ___________________________________________________________________ 000p8kXIz5Tc1GaxYYXjAfgm7YJOZvyBJxVXMi0lhaJXT22IdDbE6vVhWXW9FkRBxQ __________________________________________________________________ Now '00/' sorts before '000'. It might be a nice improvement to the --debug output to avoid putting _ under any character that sort ignored due to -d before calling strcoll() (which would help the output of the LC_ALL=3DC case, but not the en_US.UTF-8 case) - but that's probably difficult to implement. >=20 > Plz fix. There's nothing to fix but your usage pattern. So I'm closing this as not a bug. But feel free to reply further if you still have questions. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --Acc8tQTxl9UluT0Tq1fjCOewgmrvWTwcp 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/VNAAoJEKeha0olJ0NqYrkH/05+9KkJfn2EsyUBhdvQELuu MzPdJZmYsZC3suU2hyMhz19d7W/xcHxnvHq6FUPS5jfA2ZUyLeVYCxRMKc791BkT XCbRmYvr0lnXbomUXGspJFTRtXx3fTkodr7ZL1mvIE8cOhFBjqRnLZNZZ5/GzSND Q30AOv9+dM3mflhgl5zpGUeTPTvldl69YKXgYojNqsl/cbn75EmKrHCZOqps7Jqu fPdcyDqZZvn/NRaRzv4VV+aFD/2vW8BeBdCXd8L1mKrVdqL9oTJyuAbPUZBy/LlV PgC4do0CZQwamQ98DdP9hnTVcPAIhcYDJRjKNQN1s0jofHBGvS8gbmxJx8YWKjU= =OJ8G -----END PGP SIGNATURE----- --Acc8tQTxl9UluT0Tq1fjCOewgmrvWTwcp-- ------------=_1396700524-29798-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 5 Apr 2014 02:26:07 +0000 Received: from localhost ([127.0.0.1]:35796 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWGJ4-0006wm-88 for submit@debbugs.gnu.org; Fri, 04 Apr 2014 22:26:06 -0400 Received: from eggs.gnu.org ([208.118.235.92]:49385) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWG0h-0006PH-By for submit@debbugs.gnu.org; Fri, 04 Apr 2014 22:07:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WWG0g-0000tw-Co for submit@debbugs.gnu.org; Fri, 04 Apr 2014 22:07:07 -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.0 required=5.0 tests=BAYES_20,FREEMAIL_FROM, HTML_MESSAGE,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:33155) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WWG0g-0000ts-9o for submit@debbugs.gnu.org; Fri, 04 Apr 2014 22:07:06 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51107) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WWG0f-00029P-FO for bug-coreutils@gnu.org; Fri, 04 Apr 2014 22:07:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WWG0e-0000ti-PY for bug-coreutils@gnu.org; Fri, 04 Apr 2014 22:07:05 -0400 Received: from mail-wg0-x22f.google.com ([2a00:1450:400c:c00::22f]:51520) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WWG0e-0000te-IC for bug-coreutils@gnu.org; Fri, 04 Apr 2014 22:07:04 -0400 Received: by mail-wg0-f47.google.com with SMTP id x12so4177373wgg.18 for ; Fri, 04 Apr 2014 19:07:02 -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=AAhHX/9nLMM51nlJtOsBrCdbvQUzUFyaT+fLpO+zgzE=; b=dDZIIr5vrt152u+NWpeE4OlHzOm5JZHP+WYbK+MTniusmtv/pPgASj5EFLEK/qv5S9 BuoaTLwi7sCr6rSyOggMZZFRbMSzZp7IVdZswMxUgSykxvdB4V+H3AG+3h5fZyBJ3f34 N4QpMnG3vVI1VX4A7UdjwrircHw9wBflRSXsr96DKBlwZ4YffgkNd2IMgf/POEoVWd82 qoSvOmtawSZ4lZMe/eYFCCPlmm0IBypa7A0V0bB6XX9ryBhq/E1BP81RpFsEC2U7Ke6C HxGyOi/JP4ULFEUVo1cW3USO2LbtjwAQTOfs+PVcdGHhcfau/nmydEci1pS+UqXzjLBW wWCw== MIME-Version: 1.0 X-Received: by 10.180.12.147 with SMTP id y19mr8532373wib.39.1396663622408; Fri, 04 Apr 2014 19:07:02 -0700 (PDT) Received: by 10.194.165.65 with HTTP; Fri, 4 Apr 2014 19:07:02 -0700 (PDT) Date: Sat, 5 Apr 2014 05:07:02 +0300 Message-ID: Subject: Sort bugs From: Nikos Balkanas To: bug-coreutils@gnu.org Content-Type: multipart/alternative; boundary=001a11c21ba615a11c04f642173f 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-Mailman-Approved-At: Fri, 04 Apr 2014 22:26:05 -0400 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 (----) --001a11c21ba615a11c04f642173f Content-Type: text/plain; charset=ISO-8859-1 Hi, Sort is seriously bugged. This is the output from: sort -d -t \t -k1 input > out 0009rN2S3cohd2DGH6yuTWBoeuq6DwWZhCBDEnFzYqpw984FfALy7NUhEZH1.YEbiq/ 000EMQeKUjtyXIOaUkT.XE6SaBIdOqTA0nffF394V6tkcVdup2c3ihi7yhbuRof2Y5agTG 000p8kXIz5Tc1GaxYYXjAfgm7YJOZvyBJxVXMi0lhaJXT22IdDbE6vVhWXW9FkRBxQ 00/0QwzaXrqGHXW7mE9Le8IIVgHoZvccgGydKdzJgh8.SZenbULmIWMtrGShz24W7T 000R2cnZ8.khe1eXDERclkbXASRQeKvcNBaCJRLX617Xvmff0KaoZSSFBNhNG1OiIyr Shouldn't 00/0 be first according to Ascii code? Plz fix. TIA, Nikos --001a11c21ba615a11c04f642173f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,=

=
Sort is seriously bu= gged. This is the output from:

sort -d -t \t -k1 input > o= ut

0009rN2S3cohd2DGH6yuTWBoeuq6DwWZhCBDEnFzYqpw984FfALy7NUhEZH1.YEbiq/
000E= MQeKUjtyXIOaUkT.XE6SaBIdOqTA0nffF394V6tkcVdup2c3ihi7yhbuRof2Y5agTG
000p8= kXIz5Tc1GaxYYXjAfgm7YJOZvyBJxVXMi0lhaJXT22IdDbE6vVhWXW9FkRBxQ
00/0QwzaXr= qGHXW7mE9Le8IIVgHoZvccgGydKdzJgh8.SZenbULmIWMtrGShz24W7T
000R2cnZ8.khe1eXDERclkbXASRQeKvcNBaCJRLX617Xvmff0KaoZSSFBNhNG1OiIyr

Shouldn't 00/0 be first ac= cording to Ascii code?

Plz fix.

TIA,
Nikos

--001a11c21ba615a11c04f642173f-- ------------=_1396700524-29798-1-- 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 unknown Mon Jun 23 04:14:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17188: Sort bugs Resent-From: Nikos Balkanas Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Sat, 05 Apr 2014 18:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17188 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: notabug To: Eric Blake Cc: 17188-done@debbugs.gnu.org Received: via spool by 17188-done@debbugs.gnu.org id=D17188.139672336115577 (code D ref 17188); Sat, 05 Apr 2014 18:43:02 +0000 Received: (at 17188-done) by debbugs.gnu.org; 5 Apr 2014 18:42:41 +0000 Received: from localhost ([127.0.0.1]:37058 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWVY7-00043A-Tt for submit@debbugs.gnu.org; Sat, 05 Apr 2014 14:42:40 -0400 Received: from mail-wg0-f46.google.com ([74.125.82.46]:55535) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWVY0-00042v-Qu for 17188-done@debbugs.gnu.org; Sat, 05 Apr 2014 14:42:33 -0400 Received: by mail-wg0-f46.google.com with SMTP id b13so4962559wgh.5 for <17188-done@debbugs.gnu.org>; Sat, 05 Apr 2014 11:42:31 -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=Jt7XWunmcbqyWQFZ3gw8ytZM7quydq4zZYeB85573FA=; b=dxi4wZuJDFBOY1xIJFyeu3zpAJ8gDi1Aqi3lZEZLGJwfdrBbfb4CJf6LNvgKoj1i2G iWkA7fJXRMVQavg+a1xGuohkCWkiH/BsJ5nf5dZCRaa8aJli1tMMr3E97UUSXOKhc876 e3lNcCsZpkgHHKIwo3aPAK4hQKfGuliWIlW54gsUkS5Dqe31mBNo+ykLyfefsznaSjqZ D0tmpCjmj8r28aNVL46+FKUhuIDf1HWuAZJrCGng79eYLLHjc+wg4nQRyUGS3Rlb9iyz im6Gd/wPvxlh1b+q0n8cOoTTSX8D80wzPTf211+VW533WxP1WzZ6OppZgivjPVJfqJkb 629g== MIME-Version: 1.0 X-Received: by 10.180.12.14 with SMTP id u14mr13912653wib.0.1396723351526; Sat, 05 Apr 2014 11:42:31 -0700 (PDT) Received: by 10.194.165.65 with HTTP; Sat, 5 Apr 2014 11:42:31 -0700 (PDT) In-Reply-To: <533FF54D.5030404@redhat.com> References: <533FF54D.5030404@redhat.com> Date: Sat, 5 Apr 2014 21:42:31 +0300 Message-ID: From: Nikos Balkanas Content-Type: multipart/alternative; boundary=001a11c23ed237a29f04f64fff6b X-Spam-Score: -0.7 (/) 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 (/) --001a11c23ed237a29f04f64fff6b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Apr 5, 2014 at 3:21 PM, Eric Blake wrote: > tag 17188 notabug > thanks > > On 04/04/2014 08:07 PM, Nikos Balkanas wrote: > > Hi, > > > > Sort is seriously bugged. This is the output from: > > > > sort -d -t \t -k1 input > out > > -d says to do a dictionary sort that ignores non-alphanumeric > characters. But it still leaves it up to your current locale on whether > those non-alpha characters are collated case-insensitively. > > Also, '-k1' is almost always wrong - you generally want '-k1,1' if you > want to sort by JUST the first field, rather than by the whole line. > =E2=80=8BSorting by the first line? What is that? Sort should work on each = line by given columns Unix man: KEYDEF is F[.C][OPTS][,F[.C][OPTS]] for start and stop position, where F is a field number and C a character position in the field; both are ori=E2= =80=90 gin 1, and the stop position defaults to the line's end... In retrospect this confirms your saying. However, on first look, it doesn't make sense. An example like the one you gave me, in the man page would save a lot of explaining. > See the FAQ: > > https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Sort-does-n= ot-sort-in-normal-order_0021 > > =E2=80=8BFrom that link:=E2=80=8B =E2=80=8B"So far there is still no fully satisfactory solution to this prob= lem. If you find one then please contact me so that this information can be listed.= " If you are "me", then I would like to suggest that you make default the legacy sort behaviour, and add with -c the locale support that standards and non-English users ask for. > > > 0009rN2S3cohd2DGH6yuTWBoeuq6DwWZhCBDEnFzYqpw984FfALy7NUhEZH1.YEbiq/ > > 000EMQeKUjtyXIOaUkT.XE6SaBIdOqTA0nffF394V6tkcVdup2c3ihi7yhbuRof2Y5agTG > > 000p8kXIz5Tc1GaxYYXjAfgm7YJOZvyBJxVXMi0lhaJXT22IdDbE6vVhWXW9FkRBxQ > > 00/0QwzaXrqGHXW7mE9Le8IIVgHoZvccgGydKdzJgh8.SZenbULmIWMtrGShz24W7T > > 000R2cnZ8.khe1eXDERclkbXASRQeKvcNBaCJRLX617Xvmff0KaoZSSFBNhNG1OiIyr > > > > Shouldn't 00/0 be first according to Ascii code? > =E2=80=8BI have to sort billions of these hashes in TB sizes of files. Thes= e are followed by a and a key (therefore the -t \t). I was considering downloading legacy sort sources and compiling for my system. Or taking recent sources and fixing the source. Both dreadful aspects, because it would make my system incompatible and inconsistent. You don't know how happy you make me, that i can still get legacy behaviour out of the modern releases. There's nothing to fix but your usage pattern. So I'm closing this as > not a bug. But feel free to reply further if you still have questions. > =E2=80=8BUI is still a bug, though not a code bug. And legacy UI compatibil= ity is broken. However, I am perfectly satisfied with your fast and long explanation of what the status is. You will, however, go crazy if you respond like that to every user with a locale sorting issue. Can't you make default LOCALE=3DC for sorting and allow users to change that to the system settings using -c when they need it? Nowadays users use other graphical tools to do sorting, sort is used mostly by scripts. Thank you, Nikos > > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org > > --001a11c23ed237a29f04f64fff6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


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

On 04/04/2014 08:07 PM, Nikos Balkanas wrote:
> Hi,
>
> Sort is seriously bugged. This is the output from:
>
> sort -d -t \t -k1 input > out

-d says to do a dictionary sort that ignores non-alphanumeric
characters. =C2=A0But it still leaves it up to your current locale on wheth= er
those non-alpha characters are collated case-insensitively.

Also, '-k1' is almost always wrong - you generally want '-k1,1&= #39; if you
want to sort by JUST the first field, rather than by the whole line.

=E2=80=8BSorting by the first line? What is that? Sort should work on = each line by given columns

Unix man:

KEYDEF is F[.C][OPTS][,F[.C][OPTS]] for start and stop position, where F is a field number and C a character position in the field; both ar= e ori=E2=80=90
=C2=A0 gin 1, and the stop position defaults to t= he line's end...

In retrospect this confi= rms your saying. However, on first look, it doesn't make sense. An exam= ple
like the one you gav= e me, in the man page would save a lot of explaining.=C2=A0


See the FAQ:
https://www.gnu.or= g/software/coreutils/faq/coreutils-faq.html#Sort-does-not-sort-in-normal-or= der_0021


=E2=80=8BFrom that link:=E2=80=8B
=E2=80=8B"So far there is= still no fully satisfactory solution to this problem. If you find one then= please contact me so that this information can be listed."

If you are "me", the= n I would like to suggest that you make default the legacy sort behaviour, = and add with -c the locale support
that standards and n= on-English users ask for.

>
> 0009rN2S3cohd2DGH6yuTWBoeuq6DwWZhCBDEnFzYqpw984FfALy7NUhEZH1.YEbiq/ > 000EMQeKUjtyXIOaUkT.XE6SaBIdOqTA0nffF394V6tkcVdup2c3ihi7yhbuRof2Y5agTG=
> 000p8kXIz5Tc1GaxYYXjAfgm7YJOZvyBJxVXMi0lhaJXT22IdDbE6vVhWXW9FkRBxQ
> 00/0QwzaXrqGHXW7mE9Le8IIVgHoZvccgGydKdzJgh8.SZenbULmIWMtrGShz24W7T
> 000R2cnZ8.khe1eXDERclkbXASRQeKvcNBaCJRLX617Xvmff0KaoZSSFBNhNG1OiIyr >
> Shouldn't 00/0 be first according to Ascii code?

=E2=80=8BI have to sort billions of these hashes in TB sizes of fil= es. These are followed by a <TAB> and a key (therefore the -t \t).
I was considering downloading legacy sort sources and compiling for my syst= em. Or taking recent sources and fixing the source.
Both dreadful aspects, because it woul= d make my system incompatible and inconsistent. You don't know how happ= y you make me,
that i can still get= legacy behaviour out of the modern releases.

=C2=A0There's nothing to fix but your usage pattern. =C2=A0So I'm c= losing this as
not a bug. =C2=A0But feel free to reply further if you still have questions= .

=E2=80=8BUI is still a bug, though not a code bug. And legacy = UI compatibility is broken. However, I am perfectly satisfied with your fas= t and long explanation of what the status is.
You will, however, g= o crazy if you respond like that to every user with a locale sorting issue.= =C2=A0Can't you make default LOCALE=3DC for sorting and allow users to= change that
to the system settin= gs using -c when they need it? Nowadays users use other graphical tools to = do sorting, sort is used mostly by scripts.

Thank you,=
Nikos


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


--001a11c23ed237a29f04f64fff6b-- From unknown Mon Jun 23 04:14:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17188: Sort bugs Resent-From: Bob Proulx Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Sat, 05 Apr 2014 20:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17188 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: notabug To: Nikos Balkanas Cc: 17188@debbugs.gnu.org Received: via spool by 17188-submit@debbugs.gnu.org id=B17188.139672941926197 (code B ref 17188); Sat, 05 Apr 2014 20:24:02 +0000 Received: (at 17188) by debbugs.gnu.org; 5 Apr 2014 20:23:39 +0000 Received: from localhost ([127.0.0.1]:37091 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWX7q-0006oT-Ml for submit@debbugs.gnu.org; Sat, 05 Apr 2014 16:23:39 -0400 Received: from joseki.proulx.com ([216.17.153.58]:44227) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWX7m-0006o5-D8 for 17188@debbugs.gnu.org; Sat, 05 Apr 2014 16:23:36 -0400 Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id 7F41B21235; Sat, 5 Apr 2014 14:23:29 -0600 (MDT) Received: by hysteria.proulx.com (Postfix, from userid 1000) id 5B5E02DCD7; Sat, 5 Apr 2014 14:23:29 -0600 (MDT) Date: Sat, 5 Apr 2014 14:23:29 -0600 From: Bob Proulx Message-ID: <20140405202329.GA24780@hysteria.proulx.com> References: <533FF54D.5030404@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-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: > Eric Blake wrote: > > See the FAQ: > > > > https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Sort-does-not-sort-in-normal-order_0021 > > > ​From that link:​ > ​"So far there is still no fully satisfactory solution to this problem. If > you find one then please contact me so that this information can be listed." > > If you are "me", then I would like to suggest that you make default > the legacy sort behaviour, and add with -c the locale support that > standards and non-English users ask for. When I wrote that I did mean within the confines of continuing to conform to the standards. :-) > ​UI is still a bug, though not a code bug. And legacy UI compatibility is > broken. Actually no. If you were really using the legacy UI then you would be using the legacy locale setting LC_ALL=C too. If you aren't then you aren't using the legacy UI. > However, I am perfectly satisfied with your fast and long > explanation of what the status is. > You will, however, go crazy if you respond like that to every user with a > locale sorting issue. I usually rant: You don't like it and I don't like it but the-powers-that-be have confused working with data on a computer with talking about working with data on a computer. They have decided that the collation ordering (sort ordering) for data should be dictionary ordering. In dictionary ordering case is folded together and punctuation is ignored. By having LANG set to any of the "en" locales the system is instructed to use dictionary sort ordering. This affects almost everything on the system that sorts. This includes commands such as 'ls' and also your shell (e.g. 'echo *') too. > Can't you make default LOCALE=C for sorting and allow users to > change that to the system settings using -c when they need it? Actually no we can't. That would break the opposite side of things where people rely upon dictionary sorting based upon their chosen locale setting. After all of these years that would be equally bad in the opposite way. I am going to say "you" here but please don't take this as hostility. It is a bad word in text email. But I am really just trying to put down the facts of the case. Originally the locale was C. If you go back to the C locale things will be working for you as you wish it to work. It will work as it worked before. Agreed? Then you changed something. You changed the locale. You in your environment set LANG=en_US.UTF-8 (or similar equivalent). That is when you notice that sort doesn't work as you want it to work. Now you might say that you personally didn't make that choice but your system vendor did. It happened when you switched to a new machine running a newer system or something. Okay. But you chose that system vendor. You could choose a different system vendor. Or choose to go back to the previous system with the previous LANG=C locale. Or choose to configure the new system as you wish it. You are in control of it. As a pilot we have a saying, "Fly the airplane. Don't let the airplane fly you." :-) You could file bugs with your system vendor that they defaulted you to LANG=en_US.UTF-8 and ask them to allow users to choose LANG=C at install time instead. I have done this and unfortunately the response from one vendor was "That was intentional." with the bug closed and locked against further comment. The door slammed in my face. I am now using a different software distribution. > Nowadays users use other graphical tools to do sorting, sort is used > mostly by scripts. For you perhaps. Not for me. Not for many people. I have no idea what the survey count would be either way but it doesn't matter. Can't make the mistake of assuming that any one environment is more important to the exclusion of all others. But you see the problem isn't a change in sort. The problem is a change in locale. Sort is behaving as it has for years and years. What changed was the locale that most people get by default. It used to be that users would get LANG=C. But these days most users get LANG=en_US.UTF-8. But with a dictionary collating sort order locale it behaves undesirably to many of us. But to others that is exactly what they want. And so they wrote it into the locale. Two opposing viewpoints that being in opposition cannot be converged. Note that this is bigger than just sort. This affects everything on your system. It affects the shell. Try "echo *" and look at the sort ordering. Same thing there. The shell will sort by locale sort order. The only way to fix it is to fix it at the source of the problem. The source is the locale collation sequence. Which is why I always set this in my environment. export LANG=en_US.UTF-8 export LC_COLLATE=C But while that works for most western locales I have no idea how that would interact with chinese big5 for example. Probably badly. So it can't really be offered as a general solution to the problem. But if you are using one of the set of western locales that it works for then it does solve the problem for you. I keep thinking that one of these days I should dig into it and create my own locale. Something like LANG=en_US.C.UTF-8 that would define a sane sort ordering that wouldn't require LC_COLLATE=C to fix. But there isn't much itch to scratch there since LC_COLLATE=C does effectively the same thing to fix the problem. For western locales anyway and we don't usually hear from anyone else with this problem. Bob From unknown Mon Jun 23 04:14:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17188: Sort bugs Resent-From: Nikos Balkanas Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Sat, 05 Apr 2014 20:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17188 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: notabug To: Bob Proulx Cc: 17188@debbugs.gnu.org Received: via spool by 17188-submit@debbugs.gnu.org id=B17188.139673069728514 (code B ref 17188); Sat, 05 Apr 2014 20:45:02 +0000 Received: (at 17188) by debbugs.gnu.org; 5 Apr 2014 20:44:57 +0000 Received: from localhost ([127.0.0.1]:37100 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWXST-0007Pp-1t for submit@debbugs.gnu.org; Sat, 05 Apr 2014 16:44:57 -0400 Received: from mail-wi0-f169.google.com ([209.85.212.169]:44413) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWXSP-0007Pc-DF for 17188@debbugs.gnu.org; Sat, 05 Apr 2014 16:44:54 -0400 Received: by mail-wi0-f169.google.com with SMTP id hm4so4306031wib.4 for <17188@debbugs.gnu.org>; Sat, 05 Apr 2014 13:44:52 -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=ViodWZm3PNauSLQuhAvAHk8y4jYHELPz7Q1X70CknDc=; b=u0Jcx/FhIkMAGklclEm3ZHGvmiBMSi+sTLpPqbVVtNyiXpi/CMmEk7RWxCfkSDS7K7 P8frWfNKjICJ9uo2AwpVZvB9BZdmGqrwdRIJ8982dk40gGIO1fupdvAdrCz6pqXDQwIG +z7qTmO0Y5RdaoooAP8C7BxcKVjwPf7hrL0AmUwASYjAF4d1ebJRhekSgAzR8zUDRNN7 hXQuBm86flPIsul7T2C/A1VcEEoAEpDVi4PBoBjIm2G7mZneSAY7Q3S6Tt3HvUV8h+jm tjI7yELfTf+nPe8hjcO3MlvvPAeqNBFa+MJjBsdaSjhTKThmFf4jlh2P6DIAd1WEzWjy PKoA== MIME-Version: 1.0 X-Received: by 10.194.174.197 with SMTP id bu5mr29509151wjc.71.1396730692453; Sat, 05 Apr 2014 13:44:52 -0700 (PDT) Received: by 10.194.165.65 with HTTP; Sat, 5 Apr 2014 13:44:52 -0700 (PDT) In-Reply-To: <20140405202329.GA24780@hysteria.proulx.com> References: <533FF54D.5030404@redhat.com> <20140405202329.GA24780@hysteria.proulx.com> Date: Sat, 5 Apr 2014 23:44:52 +0300 Message-ID: From: Nikos Balkanas Content-Type: multipart/alternative; boundary=089e013d1a60c548f304f651b411 X-Spam-Score: -0.7 (/) 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 (/) --089e013d1a60c548f304f651b411 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 5, 2014 at 11:23 PM, Bob Proulx wrote: [...snip...] > Originally the locale was C. If you go back to the C locale things > will be working for you as you wish it to work. It will work as it > worked before. Agreed? > > Then you changed something. You changed the locale. You in your > environment set LANG=en_US.UTF-8 (or similar equivalent). That is > when you notice that sort doesn't work as you want it to work. > What about sorting input based on the input's locale, instead of the system's? Sort can distinguish ASCII (iso) from UTF-8 and collate accordingly. Even users in UTF-8 systems (like me) get ASCII files smts and need to collate them correctly. For sanity purposes users could override the locale with a command line option. [...snip...] > > The only way to fix it is to fix it at the source of the problem. The > source is the locale collation sequence. Which is why I always set > this in my environment. > > export LANG=en_US.UTF-8 > export LC_COLLATE=C > > But while that works for most western locales I have no idea how that > would interact with chinese big5 for example. Probably badly. So it > can't really be offered as a general solution to the problem. But if > you are using one of the set of western locales that it works for then > it does solve the problem for you. > That is dangerous. I don't know how much software will stop working correctly because of that. Of course, one can always return locale back to its original value, but problems might not be that obvious at all :-( [...snip...] > Bob > --089e013d1a60c548f304f651b411 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sat= , Apr 5, 2014 at 11:23 PM, Bob Proulx <bob@proulx.com> wrote:

[...s= nip...]


Originally the locale was C. =A0If you go back to the C locale things
will be working for you as you wish it to work. =A0It will work as it
worked before. =A0Agreed?

Then you changed something. =A0You changed the locale. =A0You in your
environment set LANG=3Den_US.UTF-8 (or similar equivalent). =A0That is
when you notice that sort doesn't work as you want it to work.

What about sorting input based on the input's locale, instead of the= system's? Sort
can distinguish ASCI= I (iso) from UTF-8 and collate accordingly. Even users in UTF-8
systems (like me) get ASCI= I files smts and need to collate them correctly. For sanity
purposes users could= override the locale with a command line option.

[...snip...]

=A0 The only way to fix it is to fix it at the source of the problem. =A0The source is the locale collation sequence. =A0Which is why I always set
this in my environment.

=A0 export LANG=3Den_US.UTF-8
=A0 export LC_COLLATE=3DC

But while that works for most western locales I have no idea how that
would interact with chinese big5 for example. =A0Probably badly. =A0So it can't really be offered as a general solution to the problem. =A0But if=
you are using one of the set of western locales that it works for then
it does solve the problem for you.

That is dangerous. I don'= t know how much software will stop working correctly because of that.
Of course, one can a= lways return locale back to its original value, but problems might not be t= hat obvious at all :-(

[...snip...]
=A0
Bob

--089e013d1a60c548f304f651b411-- From unknown Mon Jun 23 04:14:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17188: Sort bugs Resent-From: Eric Blake Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Mon, 07 Apr 2014 12:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17188 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: notabug To: Nikos Balkanas , Bob Proulx Cc: 17188@debbugs.gnu.org Received: via spool by 17188-submit@debbugs.gnu.org id=B17188.139687480331562 (code B ref 17188); Mon, 07 Apr 2014 12:47:01 +0000 Received: (at 17188) by debbugs.gnu.org; 7 Apr 2014 12:46:43 +0000 Received: from localhost ([127.0.0.1]:38898 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WX8wl-0008Cy-58 for submit@debbugs.gnu.org; Mon, 07 Apr 2014 08:46:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5114) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WX8wh-0008Co-KC for 17188@debbugs.gnu.org; Mon, 07 Apr 2014 08:46:41 -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 s37CkcMq017476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Apr 2014 08:46:38 -0400 Received: from [10.3.113.132] (ovpn-113-132.phx2.redhat.com [10.3.113.132]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s37CkbZQ003872; Mon, 7 Apr 2014 08:46:38 -0400 Message-ID: <53429E2D.7090602@redhat.com> Date: Mon, 07 Apr 2014 06:46:37 -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 References: <533FF54D.5030404@redhat.com> <20140405202329.GA24780@hysteria.proulx.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="wwMQ55O8BBKp6QWRE8r2tpN39NKv4Qs6Q" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Spam-Score: -5.3 (-----) 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) --wwMQ55O8BBKp6QWRE8r2tpN39NKv4Qs6Q Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/05/2014 02:44 PM, Nikos Balkanas wrote: > What about sorting input based on the input's locale, instead of the > system's? And how do you propose to detect the input's locale? The canonical way to tell a program what locale the input is in is by setting the environment variable LC_COLLATE and/or LC_ALL. > Sort > can distinguish ASCII (iso) from UTF-8 and collate accordingly. ASCII is a subset of UTF-8. There is no way to tell if input was intended as one or the other without setting an environment variable to make your intentions clear - but this is precisely what you already do to get sort to do what you want. And since this behavior is mandated by POSIX (the behavior of LC_ALL and friend controlling how 'sort' and all other utilities will collate, based on the definition of the chosen locale), it is better to point people to a consistent standard that will work across ALL implementations of 'sort', than it is to invent yet another non-standard knob for just GNU sort. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --wwMQ55O8BBKp6QWRE8r2tpN39NKv4Qs6Q 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/ iQEcBAEBCAAGBQJTQp4tAAoJEKeha0olJ0Nq0dIH/i/4iINYqsxjIOS4Stn2ekcU E2u+7em9jt7Xezzh7V+2o5temVLrxWUHMZ2L/umwHNwqpCWKZSL7MiIYpc1bMKJs XE1sZnYH4o4CE6mNXvBnzWwZcb/5BOBeX3nelhKDqwiKWhEv7BkxjoPOgiORyTkX +kCDhWtKc1MFTUvFd9Uedbkn4WS/3JqV772Az/yPP27/9VdrrWUERin/Gmgzwezo AsjCmeU7V6aelmn06hYFIfX8lN41gNs8af+Euil+o9ciYw9c/cb66lS90bw25rnB Wz1bRQemY3QvMWkUlHQT9tAIRkepZw/7cHHffNY5fox3Lbw94W1ncwsjK39S/1Q= =qOEo -----END PGP SIGNATURE----- --wwMQ55O8BBKp6QWRE8r2tpN39NKv4Qs6Q--