On 7/12/25 6:52 PM, Zachary Santer wrote:
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 theshell parser.
That wouldn't help the issue of associative array subscripts at all. An
associative array subscript is an arbitrary string, even if it's being
evaluated in an arithmetic context.
Further, you could only do it for ((...)). That's the only possible
context where it might make a difference. Nearly everything else is
just a WORD, or part of one, or determined at runtime.
Say you have something like
if command; then
declare -i X
X=some-random-expression
fi
How does the parser determine the assignment should be parsed as an
arithmetic expression? There are dozens of such examples.
If you really want this -- I doubt it's worth the time or effort -- you
might want to take a run at it, since you could use most of the existing
expression parsing code in expr.c.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
