fix(shellenv): propagate failed exit codes on Linux; fix e2e exit-code leak - #119
Merged
Conversation
On Linux the wrapper runs commands under util-linux script(1), which returns its own exit status unless --return is passed. A failing command therefore reported success to the shell: 'wt co nonexistent && echo ok' printed ok. The fish integration already passes --return; bash and zsh were missed. Covered by two new shellenv scenarios; both fail on Linux without the fix (verified in a container for bash and zsh) and pass with it.
"${__exit_code:-0}" only defaults when the variable is unset or empty, so
a step expecting exit code 0 inherited the previous step's non-zero code
and failed spuriously. Only the POSIX generator was affected; the fish
and PowerShell generators assign the status unconditionally.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #119 +/- ##
==========================================
+ Coverage 36.82% 36.98% +0.16%
==========================================
Files 28 28
Lines 3199 3201 +2
==========================================
+ Hits 1178 1184 +6
+ Misses 1935 1930 -5
- Partials 86 87 +1
🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two pre-existing bugs found while working on #117.
1. The bash/zsh wrapper swallows failures on Linux
The wrapper runs commands under
script(1)to give promptui a PTY. util-linux'sscriptreturns its own exit status unless--returnis passed, so on Linux a failed command reported success to the shell:BSD/macOS
scriptpropagates the child's status, which is why this never showed up locally or in macOS CI. The fish integration already passes--returnand even carries a comment explaining exactly this — bash and zsh were simply missed. Fix is the same one-flag change.2.
e2e/run.goleaks__exit_codebetween steps${__exit_code:-0}only defaults when the variable is unset or empty, so a step expecting exit code0after a step expecting non-zero inherited the stale1and failed spuriously. This is why every non-zero assertion in the suite had to useskip_shellenv+$WT_BIN. Only the POSIX generator was affected — the fish and PowerShell generators assign the status unconditionally.Regression coverage
Two new scenarios in
shellenv.yaml, both exercised through the wrapper:shellenv_propagates_failure_exit_code— a failingwt removeexits 1.shellenv_success_after_failure_exit_code— a successfulwt listafter a failing command still reports 0.Each fix is independently covered:
--returnchange in a Linux container (golang:1.25, util-linux 2.41): 4 failures (both scenarios × bash and zsh). With the fix: 213 passed, 0 failed.run.gochange on macOS:shellenv_success_after_failure_exit_codefails.Full local suite on macOS: 316 passed, 0 failed.
go vetandgofmtclean.Note
--returnis a util-linux long option. Busyboxscriptdoes not support it, so a busybox-only environment would now error rather than silently return the wrong code — but the fish integration has already shipped this assumption, and environments withoutscriptat all (Git Bash, minimal containers) take the existing fallback branch, which captures$?correctly.