Problem
functiontest_x() { assert_exec "./fails.sh" --exit 1; } # ./fails.sh exits 1| mode | result |
|---|
| default | ✓ Passed |
--strict | ✗ Error |
A successful command is fine in both modes, which is why this went unnoticed:
only the failing case breaks — and checking a failing command is the whole
point of --exit 1.
Cause
eval"$cmd">"$stdout_file"2>"$stderr_file"local exit_code=$?
--strict enables set -e, so a non-zero eval aborts the test function
right there and local exit_code=$? never runs. Both the stdin and non-stdin
branches have it.
Found via the docs
docs/common-patterns.md → "Testing Failure Cases" shows two forms, and under
--strictboth failed:
assert_exec "./src/validate_email.sh invalid-email" --exit 1 # ✗ Error
./src/validate_email.sh invalid-email; assert_general_error # ✗ Error
The second is the $?-capture trap already documented in #1170. The first was
this bug. With it fixed, the recommended form works under --strict, so the
guide's advice stands as written.
Fix
local exit_code=0 then eval … || exit_code=$?, in both branches. Declaring
and assigning together would mask the status behind local's own.
Problem
--strictA successful command is fine in both modes, which is why this went unnoticed:
only the failing case breaks — and checking a failing command is the whole
point of
--exit 1.Cause
--strictenablesset -e, so a non-zeroevalaborts the test functionright there and
local exit_code=$?never runs. Both the stdin and non-stdinbranches have it.
Found via the docs
docs/common-patterns.md→ "Testing Failure Cases" shows two forms, and under--strictboth failed:The second is the
$?-capture trap already documented in #1170. The first wasthis bug. With it fixed, the recommended form works under
--strict, so theguide's advice stands as written.
Fix
local exit_code=0theneval … || exit_code=$?, in both branches. Declaringand assigning together would mask the status behind
local's own.