fix(assert): let assert_exec assert a non-zero exit under --strict by Chemaclass · Pull Request #1208 · TypedDevs/bashunit

Chemaclass · 2026-08-14T04:56:30Z

🤔 Background

Related #1207

functiontest_x() { assert_exec "./fails.sh" --exit 1; } # ./fails.sh exits 1

mode	result
default	✓ Passed
`--strict`	✗ Error

eval"$cmd">"$stdout_file"2>"$stderr_file"local exit_code=$?# never reached: set -e aborts on the eval

Successful commands were unaffected in both modes, which is why it went
unnoticed — only the failing case breaks, and that is the whole point of
--exit 1.

💡 Changes

Capture the status in both branches: local exit_code=0 then || exit_code=$?. Declaring and assigning together would mask it behind local's own status

How it surfaced

Executing docs/common-patterns.md → "Testing Failure Cases" under --strict:
both documented forms failed. The second is the $?-capture trap already
documented in #1170; the first was this defect. With it fixed the guide's
recommended form works as written, so no doc change is needed.

assert_exec ran the command with eval "$cmd" >"$stdout_file" 2>"$stderr_file" local exit_code=$? and --strict enables set -e, so a command exiting non-zero aborted the test function on the eval and never reached the next line. The one assertion whose job is checking an exit code could not check a failing one. Successful commands were unaffected, which is why it went unnoticed. Capture the status in both branches: local exit_code=0 first, then '|| exit_code=$?'. Declaring and assigning together would mask the status behind local's own. Found by executing docs/common-patterns.md 'Testing Failure Cases' under --strict, where both documented forms failed. The other one is the $?-capture trap documented in #1170; this was a real defect underneath it, so the guide's recommended form now works as written. Closes#1207

Chemaclass · 2026-08-14T04:56:30Z

🤔 Background

Related #1207

functiontest_x() { assert_exec "./fails.sh" --exit 1; } # ./fails.sh exits 1

mode	result
default	✓ Passed
`--strict`	✗ Error

eval"$cmd">"$stdout_file"2>"$stderr_file"local exit_code=$?# never reached: set -e aborts on the eval

Successful commands were unaffected in both modes, which is why it went
unnoticed — only the failing case breaks, and that is the whole point of
--exit 1.

💡 Changes

Capture the status in both branches: local exit_code=0 then || exit_code=$?. Declaring and assigning together would mask it behind local's own status

How it surfaced

Executing docs/common-patterns.md → "Testing Failure Cases" under --strict:
both documented forms failed. The second is the $?-capture trap already
documented in #1170; the first was this defect. With it fixed the guide's
recommended form works as written, so no doc change is needed.

assert_exec ran the command with eval "$cmd" >"$stdout_file" 2>"$stderr_file" local exit_code=$? and --strict enables set -e, so a command exiting non-zero aborted the test function on the eval and never reached the next line. The one assertion whose job is checking an exit code could not check a failing one. Successful commands were unaffected, which is why it went unnoticed. Capture the status in both branches: local exit_code=0 first, then '|| exit_code=$?'. Declaring and assigning together would mask the status behind local's own. Found by executing docs/common-patterns.md 'Testing Failure Cases' under --strict, where both documented forms failed. The other one is the $?-capture trap documented in #1170; this was a real defect underneath it, so the guide's recommended form now works as written. Closes#1207

Chemaclass · 2026-08-14T04:56:30Z

🤔 Background

Related #1207

functiontest_x() { assert_exec "./fails.sh" --exit 1; } # ./fails.sh exits 1

mode	result
default	✓ Passed
`--strict`	✗ Error

eval"$cmd">"$stdout_file"2>"$stderr_file"local exit_code=$?# never reached: set -e aborts on the eval

Successful commands were unaffected in both modes, which is why it went
unnoticed — only the failing case breaks, and that is the whole point of
--exit 1.

💡 Changes

Capture the status in both branches: local exit_code=0 then || exit_code=$?. Declaring and assigning together would mask it behind local's own status

How it surfaced

Executing docs/common-patterns.md → "Testing Failure Cases" under --strict:
both documented forms failed. The second is the $?-capture trap already
documented in #1170; the first was this defect. With it fixed the guide's
recommended form works as written, so no doc change is needed.

assert_exec ran the command with eval "$cmd" >"$stdout_file" 2>"$stderr_file" local exit_code=$? and --strict enables set -e, so a command exiting non-zero aborted the test function on the eval and never reached the next line. The one assertion whose job is checking an exit code could not check a failing one. Successful commands were unaffected, which is why it went unnoticed. Capture the status in both branches: local exit_code=0 first, then '|| exit_code=$?'. Declaring and assigning together would mask the status behind local's own. Found by executing docs/common-patterns.md 'Testing Failure Cases' under --strict, where both documented forms failed. The other one is the $?-capture trap documented in #1170; this was a real defect underneath it, so the guide's recommended form now works as written. Closes#1207

Chemaclass · 2026-08-14T04:56:30Z

🤔 Background

Related #1207

functiontest_x() { assert_exec "./fails.sh" --exit 1; } # ./fails.sh exits 1

mode	result
default	✓ Passed
`--strict`	✗ Error

eval"$cmd">"$stdout_file"2>"$stderr_file"local exit_code=$?# never reached: set -e aborts on the eval

Successful commands were unaffected in both modes, which is why it went
unnoticed — only the failing case breaks, and that is the whole point of
--exit 1.

💡 Changes

Capture the status in both branches: local exit_code=0 then || exit_code=$?. Declaring and assigning together would mask it behind local's own status

How it surfaced

Executing docs/common-patterns.md → "Testing Failure Cases" under --strict:
both documented forms failed. The second is the $?-capture trap already
documented in #1170; the first was this defect. With it fixed the guide's
recommended form works as written, so no doc change is needed.

assert_exec ran the command with eval "$cmd" >"$stdout_file" 2>"$stderr_file" local exit_code=$? and --strict enables set -e, so a command exiting non-zero aborted the test function on the eval and never reached the next line. The one assertion whose job is checking an exit code could not check a failing one. Successful commands were unaffected, which is why it went unnoticed. Capture the status in both branches: local exit_code=0 first, then '|| exit_code=$?'. Declaring and assigning together would mask the status behind local's own. Found by executing docs/common-patterns.md 'Testing Failure Cases' under --strict, where both documented forms failed. The other one is the $?-capture trap documented in #1170; this was a real defect underneath it, so the guide's recommended form now works as written. Closes#1207

Chemaclass · 2026-08-14T04:56:30Z

🤔 Background

Related #1207

functiontest_x() { assert_exec "./fails.sh" --exit 1; } # ./fails.sh exits 1

mode	result
default	✓ Passed
`--strict`	✗ Error

eval"$cmd">"$stdout_file"2>"$stderr_file"local exit_code=$?# never reached: set -e aborts on the eval

Successful commands were unaffected in both modes, which is why it went
unnoticed — only the failing case breaks, and that is the whole point of
--exit 1.

💡 Changes

Capture the status in both branches: local exit_code=0 then || exit_code=$?. Declaring and assigning together would mask it behind local's own status

How it surfaced

Executing docs/common-patterns.md → "Testing Failure Cases" under --strict:
both documented forms failed. The second is the $?-capture trap already
documented in #1170; the first was this defect. With it fixed the guide's
recommended form works as written, so no doc change is needed.

assert_exec ran the command with eval "$cmd" >"$stdout_file" 2>"$stderr_file" local exit_code=$? and --strict enables set -e, so a command exiting non-zero aborted the test function on the eval and never reached the next line. The one assertion whose job is checking an exit code could not check a failing one. Successful commands were unaffected, which is why it went unnoticed. Capture the status in both branches: local exit_code=0 first, then '|| exit_code=$?'. Declaring and assigning together would mask the status behind local's own. Found by executing docs/common-patterns.md 'Testing Failure Cases' under --strict, where both documented forms failed. The other one is the $?-capture trap documented in #1170; this was a real defect underneath it, so the guide's recommended form now works as written. Closes#1207

Chemaclass · 2026-08-14T04:56:30Z

🤔 Background

Related #1207

functiontest_x() { assert_exec "./fails.sh" --exit 1; } # ./fails.sh exits 1

mode	result
default	✓ Passed
`--strict`	✗ Error

eval"$cmd">"$stdout_file"2>"$stderr_file"local exit_code=$?# never reached: set -e aborts on the eval

Successful commands were unaffected in both modes, which is why it went
unnoticed — only the failing case breaks, and that is the whole point of
--exit 1.

💡 Changes

Capture the status in both branches: local exit_code=0 then || exit_code=$?. Declaring and assigning together would mask it behind local's own status

How it surfaced

Executing docs/common-patterns.md → "Testing Failure Cases" under --strict:
both documented forms failed. The second is the $?-capture trap already
documented in #1170; the first was this defect. With it fixed the guide's
recommended form works as written, so no doc change is needed.

assert_exec ran the command with eval "$cmd" >"$stdout_file" 2>"$stderr_file" local exit_code=$? and --strict enables set -e, so a command exiting non-zero aborted the test function on the eval and never reached the next line. The one assertion whose job is checking an exit code could not check a failing one. Successful commands were unaffected, which is why it went unnoticed. Capture the status in both branches: local exit_code=0 first, then '|| exit_code=$?'. Declaring and assigning together would mask the status behind local's own. Found by executing docs/common-patterns.md 'Testing Failure Cases' under --strict, where both documented forms failed. The other one is the $?-capture trap documented in #1170; this was a real defect underneath it, so the guide's recommended form now works as written. Closes#1207

Chemaclass · 2026-08-14T04:56:30Z

🤔 Background

Related #1207

functiontest_x() { assert_exec "./fails.sh" --exit 1; } # ./fails.sh exits 1

mode	result
default	✓ Passed
`--strict`	✗ Error

eval"$cmd">"$stdout_file"2>"$stderr_file"local exit_code=$?# never reached: set -e aborts on the eval

Successful commands were unaffected in both modes, which is why it went
unnoticed — only the failing case breaks, and that is the whole point of
--exit 1.

💡 Changes

Capture the status in both branches: local exit_code=0 then || exit_code=$?. Declaring and assigning together would mask it behind local's own status

How it surfaced

Executing docs/common-patterns.md → "Testing Failure Cases" under --strict:
both documented forms failed. The second is the $?-capture trap already
documented in #1170; the first was this defect. With it fixed the guide's
recommended form works as written, so no doc change is needed.

assert_exec ran the command with eval "$cmd" >"$stdout_file" 2>"$stderr_file" local exit_code=$? and --strict enables set -e, so a command exiting non-zero aborted the test function on the eval and never reached the next line. The one assertion whose job is checking an exit code could not check a failing one. Successful commands were unaffected, which is why it went unnoticed. Capture the status in both branches: local exit_code=0 first, then '|| exit_code=$?'. Declaring and assigning together would mask the status behind local's own. Found by executing docs/common-patterns.md 'Testing Failure Cases' under --strict, where both documented forms failed. The other one is the $?-capture trap documented in #1170; this was a real defect underneath it, so the guide's recommended form now works as written. Closes#1207

Chemaclass · 2026-08-14T04:56:30Z

🤔 Background

Related #1207

functiontest_x() { assert_exec "./fails.sh" --exit 1; } # ./fails.sh exits 1

mode	result
default	✓ Passed
`--strict`	✗ Error

eval"$cmd">"$stdout_file"2>"$stderr_file"local exit_code=$?# never reached: set -e aborts on the eval

Successful commands were unaffected in both modes, which is why it went
unnoticed — only the failing case breaks, and that is the whole point of
--exit 1.

💡 Changes

Capture the status in both branches: local exit_code=0 then || exit_code=$?. Declaring and assigning together would mask it behind local's own status

How it surfaced

Executing docs/common-patterns.md → "Testing Failure Cases" under --strict:
both documented forms failed. The second is the $?-capture trap already
documented in #1170; the first was this defect. With it fixed the guide's
recommended form works as written, so no doc change is needed.

assert_exec ran the command with eval "$cmd" >"$stdout_file" 2>"$stderr_file" local exit_code=$? and --strict enables set -e, so a command exiting non-zero aborted the test function on the eval and never reached the next line. The one assertion whose job is checking an exit code could not check a failing one. Successful commands were unaffected, which is why it went unnoticed. Capture the status in both branches: local exit_code=0 first, then '|| exit_code=$?'. Declaring and assigning together would mask the status behind local's own. Found by executing docs/common-patterns.md 'Testing Failure Cases' under --strict, where both documented forms failed. The other one is the $?-capture trap documented in #1170; this was a real defect underneath it, so the guide's recommended form now works as written. Closes#1207

Chemaclass added the bug Something isn't working label Aug 14, 2026

Chemaclass self-assigned this Aug 14, 2026

Chemaclass merged commit 54fe83c into mainAug 14, 2026
37 checks passed