On Fri, Jul 11, 2025 at 3:13 PM Chet Ramey <chet.ra...@case.edu> wrote:
>
> This means that arithmetic syntax errors are detected when the expression
> is evaluated, not when the (( command is parsed. This is due to its origins
> as syntactic sugar for `let "expression".
>
> The [[ conditional command, on the other hand, is parsed as part of the
> shell parser. This means that syntax errors like ${op} are detected at
> parse time.
Now I'm drifting into Martin Kealey's camp. I don't want a new syntax
for associative array subscripts, but I would give up some backwards
compatibility in return for having arithmetic contexts parsed by the
shell parser. I know that would make choosing an operator at runtime
not work anymore, but having to exercise all code paths just to be
sure there aren't syntax errors is a pain. Same applies to parameter
expansion syntax errors.
This might not necessarily imply no longer evaluating variables as
expressions, but I would throw that out as well. They should have to
be constants.
let is a builtin, and its argument is always just going to be a
string, so people could continue to form arithmetic expressions at
runtime using that, if they are determined to do so. Recursive
evaluation of variables as expressions could live on there as well.
Maybe then you wouldn't need all this quoting and unquoting going on
behind the scenes for the expansion of arbitrary values as associative
array keys to work in an arithmetic context. The shell parser would
have to assume that any ${variable} expansion in an arithmetic
context, outside of a subscript, is going to be a valid integer
constant. That would mean an error at evaluation time whenever that's
not the case, same as with a variable reference lacking the dollar
sign.
And then there's POSIX. Does the Austin Group let the peanut gallery
into their discussions?
