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?
--
Dan Nelson
dnel...@allantgroup.com
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
