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
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