[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