Under Bash 3.2.57(1)-release and 4.4.12(1)-release on a MacBook Pro with
a 2.9GHz Intel Core i5 CPU and 8GB 1867MHz DDR3 RAM, this shaves off
O(0.16s) from the current test suite.
Before this change:
46 tests, 0 failures
real 0m3.541s
user 0m2.125s
sys 0m0.937s
After this change:
real 0m3.372s
user 0m2.031s
sys 0m0.894s
This is part of the effort to improve performance by reducing the number
of command substitutions/subshells.
Under Bash 3.2.57(1)-release on a MacBook Pro with a 2.9GHz Intel Core
i5 CPU and 8GB 1867MHz DDR3 RAM, this shaves off O(0.15s) from the test
suite at the previous commit, but I anticipate this effect being
magnified on Windows platforms.
The `((x++))` syntax is shorthand for `let x++`. According to `help let`:
If the last ARG evaluates to 0, let returns 1; 0 is returned
otherwise.
Thus the exit status of the expression `x=0; let x++` is 1, since the post-increment `++` operator evaluates to the value of the variable before incrementing.
In Bash 4, this non-zero exit status properly triggers `set -e`'s error trap, but in Bash 3 it does not. That's why the tests were passing on OS X (Bash 3) but not Linux (Bash 4).
We can work around the problem by choosing an incrementation expression that never evaluates to 0, such as `+=` or the pre-increment `++` operator. For consistency and clarity, I've changed to `x+=1` everywhere.
Ref. #25, #27
Expr patterns are anchored to the beginning by default. Specifying
the carrot is undefined behavior and generates warnings on some versions, obscuring the
output.
