> > Since when is removal of recursive evaluation being mooted? > Not by me, but if we're going down the path of parsing numeric expressions at the same time as the surrounding shell commands, it would be useful to have some sort of lambda assignment, so an expression would be parsed and then when executed the expression itself - rather than the value resulting from evaluating it - could be assigned to a variable.
>From there it's a short step to passing parameters to such expressions. Perhaps: (( square = x -> x*x )) echo $((square(3))) is More fun: eval "(( do_op = (a,b)-> a $op b ))" > And then there's POSIX. Does the Austin Group let the peanut gallery > > into their discussions? > > They do (https://www.opengroup.org/austin/), but given how portable > this currently is... > > % cat /tmp/foo.sh > op='||' > echo $((1 $op 0)) > [bash, dash, ksh, mksh, oksh, yash, zsh all saying "1"] To be clear, I would not change the behaviour when in POSIX mode, and probably not even in normal bash mode, unless explicitly opted into (using shopt -s something or similar, or maybe if bash itself is invoked as 'bash6') ...achieving consensus to disallow it would be difficult, unless multiple > shell developers could be convinced to break backward compatibility. Making it unspecified would be another possibility, but AFAIK no > implementations justify this change either. > "Herding cats" comes to mind... (The ((...)) and "let" commands are not part of the standard.) > Hmm, so we could change those, leave $((...)) as-is, and provide the new behaviour in, say $[...]? Nah, that inconsistency would be terrible. Better to pick something new, like ${[...]} as an expansion and {[...]} as a command. Or shopt -s strict_math -Martin
