From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 16:09:43 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AAA41065672 for ; Thu, 11 Feb 2010 16:09:43 +0000 (UTC) (envelope-from ru@freebsd.org) Received: from mail.vega.ru (mail.vega.ru [90.156.167.5]) by mx1.freebsd.org (Postfix) with ESMTP id E9C048FC1F for ; Thu, 11 Feb 2010 16:09:42 +0000 (UTC) Received: from [10.100.124.99] (helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nfbbn-00094T-KK; Thu, 11 Feb 2010 19:09:39 +0300 Date: Thu, 11 Feb 2010 19:09:38 +0300 From: Ruslan Ermilov To: Dan Nelson , stable@freebsd.org Message-ID: <20100211160938.GA53792@edoofus.dev.vega.ru> References: <20100210085814.GE9748@acme.spoerlein.net> <20100210104904.GA85373@edoofus.dev.vega.ru> <20100210180535.GG9748@acme.spoerlein.net> <20100210210007.GB9318@dan.emsphone.com> <20100211074051.GI9748@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100211074051.GI9748@acme.spoerlein.net> Cc: Subject: Re: numeric sort(1) is broken on -STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 16:09:43 -0000 On Thu, Feb 11, 2010 at 08:40:51AM +0100, Ulrich Spörlein wrote: > On Wed, 10.02.2010 at 15:00:07 -0600, Dan Nelson wrote: > > In the last episode (Feb 10), Ulrich Spörlein said: > > > On Wed, 10.02.2010 at 13:49:05 +0300, Ruslan Ermilov wrote: > > > > On Wed, Feb 10, 2010 at 09:58:14AM +0100, Ulrich Spörlein wrote: > > > > > not sure if this is a pilot error, but it seems to me that gnu sort -n > > > > > is broken on at least -STABLE (couldn't test -CURRENT yet). > > > > > > > > > > It somehow does not manifest when using a simple list and sorting on a > > > > > specific column, but it always happens to me when using it in > > > > > combination with find(1). > > > > > > > > > > % truncate -s10m a; truncate -s5m b; truncate -s800k c > > > > > % find a b c -ls|sort -nk7,7 > > > > > 8 64 -rw-r--r-- 1 uqs wheel 10485760 Feb 10 09:13 a > > > > > 10 64 -rw-r--r-- 1 uqs wheel 5242880 Feb 10 09:13 b > > > > > 12 64 -rw-r--r-- 1 uqs wheel 819200 Feb 10 09:13 c > > > > > > > > I bet you're using some non-C locale for LC_NUMERIC. What does "locale" > > > > output tell you? > > > > > > Yes and no. LC_NUMERIC is still at C, LC_CTYPE is set to UTF-8, but as > > > there are no non-ASCII symbols in that output it shouldn't matter, right? > > > For me, 819200 is smaller than 10485760 in pretty much all locales. Why > > > the hell is a numeric gnusort locale dependant? Why is -g working anyway? > > > > Try adding a 'b' to your sort flags. I bet the leading spaces in front of > > your numbers are being treated as part of the sort key. Maybe de_DE.UTF-8 > > and C have different ideas of what is whitespace? > > Indeed, 'b' is working too. So I've stocked up on the number of > workarounds for this problem. What amazes me, is that no one seems to be > as shocked as I to find out something basic like sorting on a number is > not DTRT. It is a long standing issue with Russian locales as well, but there the problem manifests itself only with LC_NUMERIC, not LC_CTYPE. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer