Re: inf and nan in arithmetic expansions

[Stephane Chazelas <stephane.chazelas@gmail.com>]

2018-02-08 12:46:35 +0000, Daniel Shahaf:
[...]
> Why do we generate "inf." with a period in the first place?  I know of
> no other tool that does this.  Shouldn't we generate "inf" and "nan"
> with no period?
[...]

The idea is that we add "." for floats that don't already have
one and don't have a e/E to make sure they stay floats when used
again in an arithmetic expression. That causes all sorts of
problems with yash and ksh93 which don't do that. See
https://unix.stackexchange.com/a/422123 for a few examples.

It just looks like "inf" and "nan" were overlooked. Whether we
output "inf", "Inf" or "inf.", we'd also want to make sure
they're recognised on input.

> And then we could add 'inf' and 'nan' as readonly variables initialised to
> those respective values (as Oliver also suggests in the 19597 thread).  There
> are compatibility implications for scripts that use these variable names, but
> there is no way around them if we want to allow explicitly doing (( x = inf ))
> in user code...

But what value would you use for those variables? Or do you mean
that the shell arithmetic parser would understand "inf"/"nan" as
the infinity and not-a-number numbers and not as the variable
(otherwise with inf=inf, that would do infinite recursion)
but just make inf/nan readonly so users not be tempted to use
them as variables?

I'd also rather "inf" be used instead of "inf." (would also
align with ksh93), but the change could potentially break some
scripts. If we also make $inf/$nan read-only variables, that
would  also break scripts that use $inf/$nan variables but not
in arithmetic contexts (like for inf in *.inf), so that doesn't
sound like a good idea to me.

-- 
Stephane