Re: Command-line program to convert 'human' sizes?

[Jim Meyering]

Pádraig Brady wrote:

> On 12/04/2012 11:35 PM, Assaf Gordon wrote:
>> Pádraig Brady wrote, On 12/04/2012 06:11 PM:
>>> On 12/04/2012 10:55 PM, Assaf Gordon wrote:
>>>> Hello,
>>>>
>>>>> Pádraig Brady wrote, On 12/04/2012 11:30 AM:
>>>>>> Nothing yet. The plan is to make a numfmt command available with
>>>>>> this interface:
>>>>>> http://lists.gnu.org/archive/html/coreutils/2012-02/msg00085.html
>>>>>>
>>>>
>>>> Attached is a patch, with a proof-of-concept working 'numfmt'.
>>>>
>>>
>>> Thanks a lot for working on this.
>>> All I'll say at this stage is to take it
>>> as far as you can as per the interface specified
>>> at the above URL with a mind to reusing stuff from
>>> lib/human.c if possible.
>>>
>>> We'll review it then with a view to including it ASAP.
>>
>> Thanks!
>>
>> Input-wise, I had to copy and modify the xstrtol implementation,
>> because the original function doesn't allow the caller to force SI
>> or IEC or AUTO (it has internal logic to deduce it, based on
>> parameters and user input).
>
> We can tweak xstrtol() in gnulib if needed
> I suppose we can refactor after.
>
>> Output-wise, "human_readable()" from "lib/human.c" is called as-is
>> (no code modification).
>>
>> Regarding the advanced options:
>> 1. I'm wondering what is the reason/need for "--to=<NUMBER>" ? It
>> base different than 1024/1000 would result in values like "4K" that
>> are very unintuitive (since they don't mean 4096/4000).
>
> Drats I can't remember now.
>
>> 2. FORMAT: is the only use-case adding spaces before/after the
>> number, and grouping?
>> "human_readable()" already has support for grouping, and padding
>> might be added with different parameters?
>
> we can do padding outside of human_readable() using mbsalign() I think,
> and that would be auto enabled with the --field option.
>
> I was thinking that --format would be a central place for tweaking
> grouping and spacing etc. of numbers using standard printf format modifiers.
>
>>
>> I'm asking about #1 and #2, because if we forgo them,
>> "human_readable()" could be used as-is. Otherwise, it will require
>> copy&pasting and some modifications.
>
> We can tweak human_readable() in gnulib if needed
> I suppose we can refactor after.
>
>>
>> 3. "SUFFIX" - is the purpose of this simply to print a string
>> following the number? or are there some more complications?
>
> That's it basically.
> It could be done with --format, but it's such a common requirement
> that I thought it warranted a separate option.
> Note human_readable() may output a 'B' suffix in certain cases,
> which it shouldn't, and we should suppress it if it does as
> noted in the spec.
>
>>
>> 4. Should nun-suffix characters following a parsed number cause
>> errors, or ignored? e.g. "4KQO"
>
> Ignored I would say.

Ignoring trailing bytes for a string like "40000O" could be misleading, no?
I'd rather get a diagnostic that there's this "O" (capital "O") at the
end of my number.   Same thing for 1's vs l's: "9111l" looks a lot like
91,111 in some fonts.