Date: Sat, 12 Jul 2025 18:52:55 -0400
From: Zachary Santer <zsan...@gmail.com>
Message-ID:
<CABkLJUJHD6YsMSFhUiJzw6xp_hUt7T8B==knjzyz1rfljjx...@mail.gmail.com>
| 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.
In general, as Lawrence said, that's never likely to happen.
| 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.
You have to exercise all paths to be sure the code actually works
anyway, when you do that, any syntax errors will get found anyway
(those are the trivial problems to fix).
| Same applies to parameter expansion syntax errors.
The NetBSD shell used to do that (and POSIX even allows it), but
it turns out to be a poor choice, and we (or I if you like) changed
it recently (in shell lifetime terms, may be a year or a bit more
ago now, I forget). Doing as you suggest (what we used to do for
parameter expansions) means that it is much more difficult to write
a script that will work using multiple shells, as doing so would mean
using only what works in all of them - instead, deferring validation
of this kind of thing means it is possible to write code which tests
which shell is running the script (or perhaps some shell capability)
and then simply write code that works for that shell, and is done a
different way (probably slower) in other shells. That doesn't
work if all syntax is parsed as the script is being read.
kre
