Re: Support in sort for human-readable numbers

[Jim Meyering]

"Vitali Lovich" <address@hidden> wrote:
...
>> because I think it's a common enough format and getting
>> more common since it's an IEC defined standard.
>>
>>> and wouldn't be better served by
>>> pre-processing the text before sort & post-processing it after as
>>> necessary?
>>
>> that's a little awkward and inefficient.
>>
>>> Supporting all the various ways the human_readable can be output is
>>> just not practical or even useful
>>
>> just ignore an optional trailing iB is all I'm suggesting.

I agree that ignoring the valid suffixes is worthwhile.
Remember that df and du support the --block-size option,
(or equivalently, via one of the BLOCK_SIZE envvars)
so people may be running "du --block-size=MiB -s /tmp",
which produces output like this:

27MiB   /tmp

As such, I'd like GNU sort to handle input like that.
You could argue that the numbers might have "." or ","
thousands separators:

  $ LC_ALL=en_US du --block-size=\'1 -s /tmp
  27,905,024      /tmp

but I don't think it's worthwhile to parse those.

>> If it's difficult or inefficient then don't worry about it.

> Right, but you have to deal with terminating characters and whatnot.
> I mean it's not super difficult obviously.  I'm just wondering why
> that logic even belongs in sort.  The rule of thumb is - the less code
> you write, the fewer bugs you'll have.

Sure, but usability counts, too.
If we stuck mindlessly to the less-code-is-better mantra,
coreutils would look very different than it does now.
Finding the right balance isn't easy.