GNU bug report logs - #50940
how df utility displays sizes - GB vs GiB

Previous Next

Full log

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Danie de Jager <danie.dejager <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: Re: bug#50940: how df utility displays sizes - GB vs GiB
Date: Fri, 1 Oct 2021 22:30:19 +0200

[Message part 1 (text/plain, inline)]

Thank you for sharing. After reading I agree that changing
existing features could break processes for users.

It would be easy to make mistakes when in a hurry and looking at the
following output:
$ df -h | grep /$
/dev/nvme0n1p1   12G  8.5G  3.6G  71% /

$ df -H | grep /$
/dev/nvme0n1p1   13G  9.1G  3.8G  71% /

I'm happy with the calculations done but as stated in the path set
mentioned I would've preferred if the output was:
$ df -h | grep /$
/dev/nvme0n1p1   12GiB  8.5GiB  3.6GiB   71% /

$ df -H | grep /$
/dev/nvme0n1p1   13GB  9.1GB  3.8GB  71% /

I propose that the options -h and -H not be changed, for compatibility, but
that it becomes possible to make a distinction between the two formats
outputs.

Can we use the same options, but to trigger the longer annotation, we
double the characters used to -hh and -HH?

therefore
$ df -hh | grep /$
/dev/nvme0n1p1   12GiB  8.5GiB  3.6GiB   71% /
$ df -HH | grep /$
/dev/nvme0n1p1   13GB  9.1GB  3.8GB  71% /

or for ls

ls -lhh *.crt
-rw-r--r--. 1 danie.dejager danie.dejager 2.6KB Sep 29 13:07 1.crt

Regards,
Danie

On Fri, 1 Oct 2021 at 18:28, Glenn Golden <gdg <at> zplane.com> wrote:

>
> A patchset submitted last year
>
>     https://lists.gnu.org/archive/html/coreutils/2020-09/msg00001.html
>
> would partially address this (for df, du, and ls) by consistently enforcing
> the semantics given in Section 2.3 of coreutils.info (8.32): If that patch
> were adopted, units suffixed with "B" (e.g. kB, MB, GB, etc.) would always
> imply base-2 units, and B-less suffixes (e.g. k, M, G) would always imply
> base-10 units, with no exceptions. ("iB" suffixes would not be used.)
>
> However, the overall issue is more complicated than this, because those
> semantics in Section 2.3 are directly contradicted by statements appearing
> elsewhere in 8.32 coreutils.info that invert the 2.3 semantics.
>
> See the above posting (and follow-ups in that thread) for all the gory
> details and historical background.
>
> NOTE: I do not know whether the program behavior and documentation
> described
> in the above post is still extant in coreutils release 9.
>
> Glenn Golden
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.