Maybe I'm wrong, but I think we can distinguish 2 cases:
- the base (base-2 or base-10) is choosen according to user's preferences :
If we display a number of bytes for example, some user may prefer to see
them displayed in base-2 (1K for 1024 bytes), some other may prefer to
see them displayed in base-10 (1.024K for 1024 bytes)
- the base is forced in software, by the developper:
IMHO it is a non-sense to display an amount of dollars or potatoes in
base-2, and base-10 should be forced. (1024 * 1024 dollars is NOT one
million dollars, it is 1.048576 million dollars).
It raises the question if the function will be used only to display
amounts of bytes (in ls, du, df, ... ), or is a more general function
that can display amounts of anything.
Assuming it should be as general as possible, maybe the function could,
if the base is choosen according to user's preferences, rely on an
environment variable to display amount either in base-2 or base-10. Then
the user could have a coherent representation of amounts amongst
softwares using the function (ls, du, df, ...)
This does not fix the suffix problem, and I still don't know how it
could be managed; maybe another ENV var to choose between ('K','M','G'
...) and ('Ki', 'Mi', 'Gi', ...) ? Maybe a silly idea ...
Yann
> On Thu, 19 Oct 2006, Eric Lowe wrote:
>
>> Clearly this is NOT the behavior you would want when you are
>> expressing KB in the computer sense, etc.
>
> "KiB" is pretty clear, whether you're aware of SI/IEC or not. If you
> are, it's even "more clear".
>
> Using the same letters for both SI (10^(3**n)) and 2^(10*n) prefixes
> is /not/ clear. E.g. go look at a listing of file sizes using, say,
> Apache and then ls -lh. Same letters but different numbers! (Arg!).
>
> I'd strongly urge we use the IEC prefixes for 2^(10*n).
>
> Failing that, if we must perpetuate the abuse of those prefixes,
> despite there being better options now, please do *not* claim the
> output uses SI prefixes in the man-pages.
>
> I'd vote against a 'B' option on the basis that it would hard-code
> this decision in applications forever more.
>
> --paulj
>
>
