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.