numeric sort(1) is broken on -STABLE
Ulrich Spörlein
uqs at FreeBSD.org
Wed Feb 10 18:05:37 UTC 2010
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:
> > Hi guys,
> >
> > 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?
% locale
LANG=
LC_CTYPE=de_DE.UTF-8
LC_COLLATE="C"
LC_TIME="C"
LC_NUMERIC="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=
% find a b c -ls | LC_ALL=C sort -nk7,7
12 64 -rw-r--r-- 1 uqs wheel 819200 Feb 10 09:13 c
10 64 -rw-r--r-- 1 uqs wheel 5242880 Feb 10 09:13 b
8 64 -rw-r--r-- 1 uqs wheel 10485760 Feb 10 09:13 a
Great, now I'm even more angry at sort(1) than before ...
Regards,
Uli
More information about the freebsd-stable
mailing list