GNU bug report logs - #47023
df utilility displays G instead of GM as unit size for Gigabytes in power of 1000

Previous Next

Package: coreutils;

Reported by: Philippe Bénézech <philippe.benezech <at> laposte.net>

Date: Tue, 9 Mar 2021 16:07:02 UTC

Severity: wishlist

Tags: wontfix

Merged with 18119

Done: Assaf Gordon <assafgordon <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Glenn Golden <gdg <at> zplane.com>
To: 47023 <at> debbugs.gnu.org
Subject: bug#47023: df utilility displays G instead of GM as unit size for Gigabytes in power of 1000
Date: Wed, 10 Mar 2021 07:50:14 -0700
Pádraig, Philippe, Paul -

Pádraig Brady [Tue, 9 Mar 2021 19:51:45 +0000]:
> 
> > On 09/03/2021 12:58, Philippe Bénézech via GNU coreutils Bug Reports wrote:
> > Dear maintener,
> > 
> > I found a reproducible bug in df utility, installed in debian stable
> > 
> > $ df --version |head -1
> > df (GNU coreutils) 8.30
> > $ cat /etc/debian_version
> > 10.8
> > 
> > df displays G instead of GM as unit size for Gigabytes in power of 1000
> > (but the value is correct)
> 
> This is not restricted to G
> 
> > $ df -BGB /home
> > Sys. de fichiers blocs de 1GB Utilisé Disponible Uti% Monté sur
> > /dev/mapper/ssd2        421GB   355GB       45GB  89% /home
> > 
> > $ df -H /home
> > Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
> > /dev/mapper/ssd2   421G    355G   45G  89% /home
> >

> 
> In summary df -H is outputting with a concise single letter, which is
> indistinguishable from that of df -h.  I agree that's not ideal as the
> output can't be interpreted without the command as context.  I.e. it
> restricts usage to direct command line usage.  A possible change we could
> make here would be to use GB, MB etc.  if --si is specified.  But also -h
> and -H are not really useful outside of direct cli usage, I'm 50:50 on
> changing this.
> 
> This was originally discussed at https://bugs.gnu.org/18119
> 

It was brought up again more recently (Sept. 2020) here:

    https://lists.gnu.org/archive/html/coreutils/2020-09/msg00001.html

The above post provided an extensive background and history of the issue,
and a suggested patchset.

>
> Mentioned there is an option to use the new numfmt functionality
> to provide more control and unambiguous output.
> 
> BTW the fact that a B suffix implies SI units is awkward in the first
> place, which I've documented the reasons for at:
> 
>     https://www.pixelbeat.org/docs/coreutils-gotchas.html#units
> 

Agree 100% with your statements therein. (And your above document is
referenced as [2] in the above-mentioned posting from September).

Imo, it would be a Very Nice Thing if the program behavior of --si would
be brought into accordance with your documentation above (and with Section
2.3 of coreutils.info, which says essentially the same things) rather than
having two sets of mutually conflicting documentation co-existing within
coreutils.  The proposed patchset does that.

See above posting for details. It's very long, but it lays out the entire
story from start to finish, with all known back references that I'm aware of.

- Glenn Golden




This bug report was last modified 4 years and 155 days ago.

Previous Next


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