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: Pádraig Brady
Subject: Re: Command-line program to convert 'human' sizes?
Date: Wed, 05 Dec 2012 01:24:58 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

On 12/05/2012 12:56 AM, Assaf Gordon wrote:
Pádraig Brady wrote, On 12/04/2012 07:31 PM:
On 12/05/2012 12:19 AM, Jim Meyering wrote:
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:
Pádraig Brady wrote, On 12/04/2012 11:30 AM:

< snip long discussion >

Would the following be acceptable:
1. remove "--to=<NUMBER>" option

I wish I could find my notes on this.
Yes ignore for now. I might remember what
I was thinking here later.

2. surplus characters following immediately after converted number trigger a 
warning (error?),
   except if the following characters match exactly the "suffix" parameter.

Right. Might as well error as give a warning?

Regarding "--format":
The implementation doesn't really use "printf", so "%d" isn't directly usable.

So we lose zero padding, base conversion, etc. but...

One option is to tell the user to use "%s" (instead of "%d"), and we'll simply put the 
result of "human_readable()" as the string parameter in vasnprintf - this will be flexible in terms 
of alignment.
Another option is the remove "--format" option, and replace it with "--padding" 
or similar.


Regarding grouping (thousands separator):
This only has an effect when no using "--to=SI" or "--to=IEC", right?
Perhaps we can add a separate option "--grouping", and simply turn on the 
"human_grouping" flag? (easy to implement).

... such features may be better with explicit options
for --padding, --grouping, --base.
Yes grouping wouldn't make much sense with --to=SI

cheers,
Pádraig.



reply via email to

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