On Wed, Jul 9, 2025 at 11:38 AM Chet Ramey wrote:
>
> If the expression hadn't contained $x, nothing would have been expanded,
> because expanding a word without any expansion characters is a waste of
> time. This arguably causes a problem in this case; it would have been
> more consistent to run
Date:Wed, 9 Jul 2025 14:00:46 -0400
From:Greg Wooledge
Message-ID: <20250709180045.ga28...@wooledge.org>
| If that's true, then I don't understand why these two commands give
| different results:
|
| (( hash[\$key]++ ))
| let "hash[\$key]++"
|
|
On 7/9/25 2:00 PM, Greg Wooledge wrote:
On Wed, Jul 09, 2025 at 11:36:59 -0400, Chet Ramey wrote:
The arithmetic expression within (( and )) is equivalent to
let "expression"
so the contents are expanded once as if in double quotes. This has
always been the case -- earlier versions of bash jus
On Wed, Jul 09, 2025 at 11:36:59 -0400, Chet Ramey wrote:
> The arithmetic expression within (( and )) is equivalent to
>
> let "expression"
>
> so the contents are expanded once as if in double quotes. This has
> always been the case -- earlier versions of bash just translated
> ((expr)) into le
On 6/30/25 5:06 AM, Isabella Bosia wrote:
this causes a parser error since commit 35bc7025
a=(0 1 2)
b=(0 1 2)
x=0
((i=$x,a[b[i]]))
using $ anywhere in (( )) makes subscripts not expandable
Not quite true; it expands them only once. Here's what I mean.
The arithmetic expression within (( and
On 7/8/25 8:32 PM, Isabella Bosia wrote:
$ fltexpr -p inf
inf
$ fltexpr -p 10**1
inf
$ fltexpr -p 1e1
bash: fltexpr: 1e1: number out of range (error token is "1e1")
can you just ignore erange? strtod returns an infinity in that case
What do you propose? Catch HUGE_VAL/ERANGE a
