GNU bug report logs - #58521
human readable still wrong output (after 20+ years?)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 58521 in the body.
You can then email your comments to 58521 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: chandler <scar <at> riseup.net>
To: bug-coreutils <at> gnu.org
Subject: human readable still wrong output (after 20+ years?)
Date: Fri, 14 Oct 2022 09:24:07 -0700

The failure to use correct prefixes is still a cause for major confusion amongst individuals especially when sharing data, and especially when other programs are involved that do correctly report file sizes. K, M, G, T, etc. have NEVER referred to base-2 values until they were incorrectly introduced into the computing world, who knows, probably 50 years ago or more. Someday maybe all computer programs will properly report file sizes. Please make corrections so that '-h' flag correctly uses prefixes Ki, Mi, Gi, Ti, etc. Or change -h default behavior to report base-10 values and add another flag to report base-2 values+prefixes. Please no excuses about how this will break other programs, that is up to their maintainers to fix given the corrected output.

Please no suggestions for users to make changes to the default environment to fix wrong output. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages coreutils depends on: ii libacl1 2.3.1-1 ii libattr1 1:2.5.1-1 ii libc6 2.35-2 ii libgmp10 2:6.2.1+dfsg1-1 ii libselinux1 3.4-1+b1 coreutils recommends no packages. coreutils suggests no packages. -- no debconf information

Message #10 received at 58521-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: chandler <scar <at> riseup.net>
Cc: 58521-done <at> debbugs.gnu.org
Subject: Re: bug#58521: human readable still wrong output (after 20+ years?)
Date: Mon, 2 Jan 2023 12:28:54 -0800

On 2022-10-14 09:24, chandler wrote:
> Please no excuses about how this will break other programs

Unfortunately backward-compatibility concerns are real, which means 
we're not likely to make a big change to -h's behavior at this point. 
You can use --si instead.

Assuming you're talking about 'df' and 'du', neither -h nor --si follows 
the SI standard, since they both output prefixes without units. So this 
is not a question of conforming to any standard.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Chandler Sobel-Sorenson <chandler <at> genome.arizona.edu>
Cc: 58521 <at> debbugs.gnu.org
Subject: Re: bug#58521: human readable still wrong output (after 20+ years?)
Date: Mon, 2 Jan 2023 13:40:22 -0800

On 2023-01-02 13:22, Chandler Sobel-Sorenson wrote:

>> Unfortunately backward-compatibility concerns are real,
> 
> Such as? 

I imagine lots of programs read the current output format. GNU 'sort' 
does. I haven't investigated all such programs.

The current behavior has been in place since Larry McVoy contributed it 
in 1996. It'd take a pretty strong argument to change it now. Mere 
dislike wouldn't suffice.

> this is about your programs outputting WRONG and INCORRECT values, 
> inconsistent with reality

"Inconsistent with reality" is hyperbole; this is merely disagreement 
about notation.

> All you need to do is add an "i" to -h's prefixes

That would bloat the output and introduce compatibility concerns as 
mentioned above.

Message #16 received at 58521-done <at> debbugs.gnu.org (full text, mbox):

From: Chandler Sobel-Sorenson <chandler <at> genome.arizona.edu>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 58521-done <at> debbugs.gnu.org
Subject: Re: bug#58521: human readable still wrong output (after 20+ years?)
Date: Mon, 2 Jan 2023 14:22:27 -0700

Paul Eggert wrote on 1/2/23 1:28 PM:
> Unfortunately backward-compatibility concerns are real,

Such as?


> which means we're not likely to make a big change to -h's behavior at this point. You can use --si instead.

While --si produces correct output, this does not address the subject of this bug, which is -h's faulty behavior.  What big change are you thinking of?  All you need to do is add an "i" to -h's prefixes.  Optionally and additionally, you could change -h's behavior so it outputs the same thing as --si, then create a new flag such as --bi for binary prefixes and values.


> Assuming you're talking about 'df' and 'du', neither -h nor --si follows the SI standard, since they both output prefixes without units.

Don't be silly, we all know what the units are, plus it is mentioned in the manuals.


> So this is not a question of conforming to any standard.

Never said it was, or maybe I mentioned it, don't remember since it's been so long.  Either way, the standard is a guideline to follow, this is about your programs outputting WRONG and INCORRECT values, inconsistent with reality.  I'm sure I'm not the only one who works with international collaborators involving terabytes of data.  After having to spend several days going back and forth explaining to them that, yes, we did deliver all the data required by the project and, no, there is no data missing, it was imperative to file this report, just as it is for your programs to output results that are in accordance with reality.

Previous Next

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