[I'm not sure why the original never made it to the list archives]

On 8/24/19 2:26 AM, Mark H Weaver wrote:
> I just learned that "ls -l --si" prints 1000000000001 as 1.1T,
> 10000000000001 as 11T, 1000000000000001 as 1.1P, etc.
> At first I thought this must be a bug, but I see now that lib/human.[ch]
> deliberately rounds to positive infinity by default, unless a different
> rounding mode is requested.  'dd' seems to be the only program in
> coreutils that requests round-to-nearest mode.
> In my opinion, this behavior is very surprising.
> To be honest, I've been misinterpreting the output of "ls -l --si" for
> many years.  I've made false assertions based on what 'ls' printed.
> I've copied the printed sizes into my writing, and when I write 1.1T, I
> mean between 1.05T and 1.15T.  That's the convention I learned at
> university, which included some study of physics and applied
> mathematics.  If nothing else, I expected --si to produce output that
> conforms to the expectations of the scientific community.
> I'm left wondering whether I should feel embarrassed for not knowing
> that 1.1T could mean 100000000001.
> I can understand the desire to round up to the nearest allocation block.
> That is sometimes desirable if one is interested in disk usage, as
> opposed to logical file size.  However, it's quite another matter to
> display (10^12 + 1) as 1.1T.
> Does anyone else find this behavior suboptimal?
> Is there a willingness to consider changing it?

It seems like it would be a reasonable change to me, if someone wants to
propose a patch.

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to