bug#21000: coreutils 8.24 sort -h gets ordering wrong

[Pádraig Brady]

tag 21000 wontfix
close 21000
stop

On 07/07/15 03:00, Christopher Samuel wrote:
> Hi there,
> 
> When trying to sort with the -h option (--human-numeric-sort) it seems
> to fail to get the ordering correct, for instance in a column of values
> of memory usage from the Slurm HPC batch system you get this:
> 
>   2868768K
>   2875504K
>   3278652K
>   3435484K
>   3461744K
>   4050208K
>    419.50M
>       421M
>       422M
>    447.50M
>       451M
>       467M
>    478.50M
>       479M
>       496M
>       998M
>      1.09G
>      1.31G
>      1.31G
>      1.31G
> 
> and yet the values in KB are far in excess of the GB values, let alone
> the MB ones (4050208K being the just over 4GB).
> 
> Looking at the source it appears that this ordering is derived purely on
> an ordering of the suffixes rather than doing any form of conversion.
> 
> I had then thought that I needed to specify the -n option as well, but
> it turns out that the -n and -h options are mutually exclusive for some
> reason.

Quoting http://www.gnu.org/software/coreutils/sort

"[-h] sorts values that are consistently scaled to the nearest suffix
 ... and it therefore sorts the output of any single invocation of the
 df, du, or ls commands that are invoked with their --human-readable option.
 ... Note also the numfmt command ..."

I.E. sort -h is not as general as you require.
You can leverage numfmt(1) though to do the required adjustments.
For example, copy/pasting this command:

echo "\
a 2868768K
b 2875504K
c 3278652K
d 3435484K
e 3461744K
f 4050208K
g  419.50M
h     421M
i     422M
j  447.50M
k     451M
l     467M
m  478.50M
n     479M
o     496M
p     998M
q    1.09G
r    1.31G
s    1.31G
t    1.31G" |
numfmt --field=2 --from=si |
sort -k2,2n |
numfmt --padding=1 --field=2 --to=si

will give this output:

g 420M
h 421M
i 422M
j 448M
k 451M
l 467M
m 479M
n 479M
o 496M
p 998M
q 1.1G
r 1.4G
s 1.4G
t 1.4G
a 2.9G
b 2.9G
c 3.3G
d 3.5G
e 3.5G
f 4.1G

cheers,
Pádraig.