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.
