test: fix two macOS bash-3.2 suite failures + silence a spurious ERR trap

[rappdw]

Three fixes from one investigation into the maintainer's macOS run, which aborted at 913 checks with 2 failures. All three are invisible to CI (Ubuntu, bash 5, no sandy on PATH).

1. §68 — the test suite was executing sandy

The assert script lives in a double-quoted python3 -c "…" string, and a Python comment inside it read:

# Regression: the proxy of a `sandy`-named workspace must join to sandy-92aa9f98,

Bash expands backticks in a double-quoted string regardless of Python comment syntax — so the suite ran the real sandy command and spliced its multi-line output into the script:

# Regression: the proxy of a [sandy] Building...
[sandy] Sandbox image up to date.-named workspace must join to sandy-92aa9f98,

The second line isn't a comment → SyntaxError: invalid decimal literal → both §68 checks fail. On CI there's no sandy on PATH, the expansion is empty, the line stays a comment, and it passes.

Beyond the false failure: a test suite silently invoking the tool under test is its own bug. That "Sandbox image up to date" is a real image check running mid-suite.

Fix: switch the block to a quoted heredoc (python3 - "$_json" <<'DFPY'), killing the whole expansion class rather than just this one backtick. python3 - ARG keeps sys.argv[1] == the JSON, so the assertions are byte-identical.

Proof (on Linux, with a fake sandy on PATH): old block FAILS — reproducing the macOS failure exactly — new block PASSES, both modes.

Same class as the Dockerfile.proxy backtick regression already guarded by §49. I scanned all 35 python3 -c "…" blocks; this was the only one.

2. §83 — nested source <(…) aborted the entire run

_hd_out="$(bash -c 'source <(sed -n "..." "$1"); ...' -- "$_S83")"

bash 3.2 doesn't reliably support process substitution nested in command substitution: the source yields nothing, both calls exit 127, the ERR trap fires, and every section after §83 never executes.

run-tests.sh already documents this trap twice in its own comments and avoids it in the _sandy_translate_args/build_* extractions. Switched to that same extract-then-eval idiom.

3. sandy:1043 — spurious "report this bug" on every macOS --print-state

_ac="$(docker exec … )" || _ac="" handles the status, but with set -E the introspection ERR trap is inherited by the substitution subshell and bash 3.2 fires it anyway. Every macOS --print-state with an unreachable tmux probe printed:

[sandy] ERROR: introspection handler failed (exit 1)
[sandy]        Report this at https://github.com/rappdw/sandy/issues

…for entirely normal behavior (a container mid-startup, or a dead session). Moved the guard inside the substitution (|| true), which silences it on both bash versions. Emitted values unchanged — verified attached_clients still 2 and null respectively.

How this was found

§68 passed standalone on the maintainer's Mac but failed in the full suite, so I instrumented _df_assert to capture cwd/env/PATH/exit-code/stderr and the Python error (which check() normally discards into /dev/null). The .pyerr file named the cause outright. That instrumentation has been removed; grep -c TEMP-DIAGNOSTIC → 0.

Possible follow-up (not included)

A guard asserting no expanding python3 -c "…" block contains a backtick or $(. This is now the second occurrence of this bug class in the repo. I left it out because a robust detector has to distinguish blocks nested inside single-quoted bash -c wrappers, and a fragile guard is worse than none — but it's worth considering.

🤖 Generated with Claude Code