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

[Pádraig Brady]

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.

thanks,
Pádraig.