I get the same 'nan' on three SL 7.9 computers, but it works ok on a
CentOS 7.9 machine. Here is an excerpt from 'rpm -qi coreutils' on
CentOS 7.9:
Source RPM : coreutils-8.22-24.el7_9.2.src.rpm
Build Date : Mon 16 Nov 2020 02:24:59 PM PST
Build Host : x86-01.bsys.centos.org
and here is the same from SL 7.9:
Source RPM : coreutils-8.22-24.el7_9.2.src.rpm
Build Date : Tue 10 Nov 2020 09:07:17 AM PST
Build Host : sl7.fnal.gov
Steven Yellin
On Wed, 10 Feb 2021, ~Stack~ wrote:
Greetings,
Curious if anyone else can replicate this. I initially saw this in a certain
upstream vendor 7.9, but I'm having issues replicating it and it's only in a
certain environment (virtual and I've done strange and awful things to that
as I've been trying to understand an unrelated project). However, I was
trying to figure out if it was other places as well. Sure enough, I can
replicate it on every single one of my SL 7.9 instances that I've tested.
The short, numfmt should not return 'nan' when passed a zero.
$ echo 0 | numfmt
nan
$ rpm -q coreutils
coreutils-8.22-24.el7_9.2.x86_64
If I try on any other distro (Ubuntu/Debian/CentOS 8), it returns 0 as it
should.
$ echo 0 | numfmt
0
$ rpm -q coreutils
coreutils-8.30-8.el8.x86_64
I may not be able to replicate it as reliably as I would prefer on upstream
vendor, but every single SL 7.9 system I've tried has had
coreutils-8.22-24.el7_9.2.x86_64 and incorrectly returns 'nan'.
I'm hoping the devs can confirm and/or offer suggestions.
Thanks!
~Stack~
