Re: sort human readable suffixes

[Cornelis de Gier]

I've created a patch <http://home.wanadoo.nl/cwdegier/sort-h.patch> 
against coreutils 5.2.1 to sort to sort human readable file sizes as 
they are emitted from df, du and ls

Paul Eggert <address@hidden> wrote about this feature

> Beware the decimal-point character: it's locale-dependent.

strtod can take care of that

> Handle both decimal and binary powers of 2, by looking for suffixes
> like "GB" (decimal) versus "G" not immediately followed by "B"
> (binary).

df, du and ls don't add a B in their human readable output.

> It's tempting to use strtod but I suspect it won't work in general
> (due to the possibility of misconstruing an 'E' suffix, for exabytes)
> and anyway it'd be faster to avoid floating-point, just as "sort -n"
> does.

The E doesn't create a problem in this example:

100P3
100E
100E3
52K

gets sorted properly:

52K
100E3
100P3
100E

Does it give problems in other situations?

Cornelis