Re: Human readable sort

[Pádraig Brady]

Michael Speer wrote:
> 2009/4/25 Pádraig Brady <address@hidden>:
>> I've further modified your latest in the attached.
>> I refactored the suffix finding a bit and also added
>> support for --sort=human-numeric.
> 
> I refactored it again to handle some potential problems with how
> separators and decimals points were handled.

find_unit_order() is a better refactoring, thanks.

> It will still let you
> write something silly like "1,3,4.5.6", but I've stopped scanning on
> "4..4" or "3,,2" or even "5.M".  I'm not sure if that last one is used
> meaningfully anywhere.

That's an improvement.
I'll have to do some benchmarking to see
if these extra checks have any significant effect.

> I did this partly to avoid breaking locales
> where space is the separator.

Supporting spaces in numbers is problematic anyway
due to the way fields are handled. Good to have
the space as thousands separator handled anyway.

> I poked around a bit to see if any locales used space.  
> Apparently, the Hungarian locale does.  I stopped looking there.

Doesn't have spaces here at least:
LANG=hu_HU.utf8 printf "%'d\n" 1234

>> I'm wondering whether "numeric" is superfluous?
>> I.E. are --sort=human and --human-sort sufficient.
>>
> 
> I started with just human, but thought it better to add the numeric
> since sort is by default for strings, and both current switches that
> enable numeric sorts have it in their name.  I would not fight a
> reversion on this if no one thought it would look confusing or too
> inconsistent to end users.

Well I was worried about it being too verbose, but it is more
consistent with other numeric options, so we'll leave it as is I think.

OK, I'll do up docs and tests tomorrow for this.
If you would prefer to do that please shout now.

cheers,
Pádraig.