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). 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). 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? 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. 3. "SUFFIX" - is the purpose of this simply to print a string following the number? or are there some more complications? 4. Should nun-suffix characters following a parsed number cause errors, or ignored? e.g. "4KQO"
