Greetings,

Thanks for checking. That seems to fit that every other distro is fine. 
But I've now check a dozen different systems on SL 7.9 and all show it.

Thanks!
~Stack~




On 2/10/21 7:37 PM, Konstantin Olchanski wrote:
> 
> here goes, all on physical machines.
> 
> sl6, macos: no numfmt, sorry
> 
> ubuntu lts 20.04, centos-7, rhel-8 (ahem!):
> 
> $ echo 0 | numfmt
> 0
> 
> perhaps your 80387 chip is faulty. (happened to us once
> on an R3000/R3010 SGI workstation)
> 
> K.O.
> 
> 
> 
> On Wed, Feb 10, 2021 at 06:17:26PM -0600, ~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~
>