test-common.bash resolves CON_BIN to /../con when sourced standalone (SC_TOP unset)

[jeonghanlee]

test-common.bash resolves CON_BIN to /../con when sourced standalone (SC_TOP unset)

Milestone

Backlog

Labels

bug, P3-low

Summary

tests/test-common.bash derives the con binary path from SC_TOP: CON_BIN="${CON_BIN:-${SC_TOP}/../con}" (line 23). SC_TOP is set by each individual test-*.bash script, not by test-common.bash itself. When test-common.bash is sourced directly in a bare shell (for debugging or ad-hoc reproduction), SC_TOP is unset, so CON_BIN resolves to /../con and con never runs — every command silently prints bash: /../con: No such file or directory.

This is not hit by the normal suite: tests/run-all-tests.bash exports a correct absolute CON_BIN, and each registered test-*.bash sets SC_TOP from its own path. The fragility only bites interactive/standalone sourcing.

Root Cause

test-common.bash depends on a variable (SC_TOP) that its own callers are responsible for setting, with no self-derivation and no guard when it is missing. The ${CON_BIN:-...} default masks the failure as a path that looks plausible but does not exist.

Impact

Debugging-time false negatives. This exact trap produced the wrong "0x14 is PTY-consumed" conclusion in issue #24: an ad-hoc source test-common.bash left CON_BIN=/../con, so con did not run and the absent diagnostic output was misread as a PTY limitation rather than con-not-running.

Proposed Fix

Make test-common.bash self-sufficient for SC_TOP, or guard it. Options to weigh:

• Derive a fallback inside test-common.bash (e.g. from BASH_SOURCE) when SC_TOP is unset.
• Fail loudly if the resolved CON_BIN is not executable, instead of defaulting to a non-existent path.

Acceptance Criteria

Sourcing tests/test-common.bash in a bare shell either resolves CON_BIN to the real binary or fails with a clear message; it never silently resolves to a non-existent /../con. The existing suites continue to pass unchanged under both echo-server backends.

Out of Scope

Issue #24 (the diagnostic test) already carries a local CON_BIN pin and is not blocked by this. No change to con.cpp.