numeric sort(1) is broken on -STABLE

[Ulrich Spörlein]

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.

Bye,
Uli