Re: Support in sort for human-readable numbers

[Vitali Lovich]

On Sun, Jan 4, 2009 at 5:35 AM, Jim Meyering <address@hidden> wrote:

> However, this assumption might be acceptable (other opinions welcome),
> on the condition that the code behind this option diagnoses any violation.

Sorry - I missed responding to this part in the previous e-mail.
Could you please clarify - what violation is the code supposed to
diagnose?  There's really no way to do so because my implementation
doesn't attempt to understand the input that it's being given: garbage
in, garbage out.  Since my implementation doesn't know how you've
defined your suffixes, so it can't really say - error - you're trying
to use a suffix, but the number line has a demarcation at 1024.  For
instance, maybe to make it nicer to display, you make 0.8 the
demarcation of when to switch to using the next suffix e.g. 800 KB/s
is actually represented as 0.8MB/s.

However, I could look at adding an option (probably not a short option
because it's use should also be discouraged since it's a debugging
flag) that would allow the user to specify the size of suffixes (i.e.
each additional suffix is an additional multiplication by 1024).
However, this would make things slightly more complicated because then
that number would have to be converted to a string to be compared
against both strings in human_compare (to avoid the issues of
converting a string to a number).  This is a trivial feature - is this
what you were thinking of (and once detected, perhaps after the sort
print some kind of warning/error that the input was not internally
consistent)?.

On a side note - additional human-based units (i.e. KB/s) could be
trivially supported through the use of sed (something along the lines
of `| sed 's/KB\/s/K/' | sort -h | sed 's/K/KB\/s/'`, but more
generic).