[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
signature.asc
Description: OpenPGP digital signature
