coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Assaf Gordon
Subject: Re: Command-line program to convert 'human' sizes?
Date: Tue, 04 Dec 2012 18:35:15 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4

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" 








reply via email to

[Prev in Thread] Current Thread [Next in Thread]