coreutils
[Top][All Lists]
Advanced

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

Re: numfmt (=print 'human' sizes) updates


From: Assaf Gordon
Subject: Re: numfmt (=print 'human' sizes) updates
Date: Fri, 01 Feb 2013 17:25:39 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4

Hello Pádraig,

Thanks for carrying this through - I think it's becoming a nice little 
addition...

Couple of small issues:

>     numfmt: Don't process fields in command args by default
>     numfmt: support a space between the number and suffix

I see where you're going with these two changes, but they lead to some 
unexpected(?) behavior.

These two are equivalent, as expected:
    $ ./src/numfmt --from=si "45K"
    45000
    $ echo "45K" | ./src/numfmt --from=si
    45000

These two are not equivalent, which is expected-or-unexpected, based on your 
personal expectations :)
    $ ./src/numfmt --from=si "45 K"
    45000
    $ echo "45 K" | ./src/numfmt --from=si
    45 K

Carefully reading the patch, it's understandable that "--field=1" is implied 
with STDIN, but not with ARGV - 
but I'm not sure this is what the common user would expect.

These two are probably unintended consequences:
    $ echo "45K hello" | ./src/numfmt --from=si            
    45000 hello
    $ ./src/numfmt --from=si "45K hello"
    ./src/numfmt: invalid suffix in input '45K hello': ' hello'
    $ ./src/numfmt --from=si "45 K hello"
    ./src/numfmt: invalid suffix in input '45 K hello': ' hello'

Where as in the previous version it "just worked", because "--field=1" was 
implied:
    $ ./src/old_numfmt --from=si "45K hello"
    45000 hello



Last, accepting white-space but not emitting them might affect auto-padding (I 
did not check it thoroughly, though):
    $ ./src/numfmt --from=si --to=iec "45K"
    44K
    $ ./src/numfmt --from=si --to=iec "45 K"
    44K
    $ ./src/numfmt --from=si --to=iec "45  K"
    44K
    $ ./src/numfmt --from=si --to=iec "45   K"
    44K



 
>     numfmt: support floating point numbers without a suffix

Technically this is perfectly valid, but what is the meaning of a float-point 
number without a suffix?
For me, the implied usage of "numfmt" is to work with units, and most commonly 
implied bytes.
So "4.6M" is implying approximately 4,600,000 units of something (usually 
bytes). But what is "4.6" ? we are dealing with implied units, should we 
consider "0.6" of a unit?
It's not a mistake/bug, just nit-picking... probably harmless to leave it and 
still support it.

>     numfmt: support negative numbers

This also goes to the meaning of negative units (e.g. negative bytes), which is 
either acceptable or not depending on your personal preference.

But this also introduces a tiny bug due to my (limited) rounding functions:

    $ ./src/numfmt --from=si -- -9K  
    -9000
    $ ./src/numfmt --from=si -- -9.1K
    -8900
    $ ./src/numfmt --from=si -- -9.2K
    -8800

And also:
    $ ./src/numfmt --to=iec -- 90000
    88K
    $ ./src/numfmt --to=iec -- -90000         
    -90000



Thanks again,
 -gordon



 




reply via email to

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