Repository navigation
fix(powershell): leave $? False when hf re-runs a failing command; 0.2.7 - #12
Merged
Merged
Conversation
hf now sets the caller's $? from the command it ran, and the runner names are registered once when the setup is sourced again. Fixes #11
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.
In PowerShell,
$?wasTrueafterhfre-ran a command that failed (#11):hfis a plain function, and a function that returns normally leaves$?True whatever ran inside it. Prompts that show the last status reported success.hfis now an advanced function. After the fixed command, a new native exit code that is not 0, or a new$Error[0], means it failed;hfthen writes an error record withErrorAction Ignore, which sets the caller's$?to False without printing anything or adding to$Error. These are the cases where$?would be False had the line been typed.$LASTEXITCODEwas already right. bash and zsh were not affected (the function returns the command's status).CODIGEST_RUNNERSonly if they are not there yet, so sourcing the setup again (. $PROFILE,source ~/.bashrc) no longer lists them twice.. __cdg { }strip in the PowerShell function stays: codigest 0.12.2, the current release, still leaves that form in the engine history (fixed on its main in feat(hook): let programs that run commands keep the terminal codigest#53, not released). The comment now says which versions need it. It can go once a codigest release with that fix is out.Version 0.2.7. This is step 1 of the codigest/hanfix design (the next steps move the re-run into codigest's Enter handling); nothing here depends on that.
Tests
tests/shells.ps1:$?is True after a successfulhf -yand False (exit code 3) after one that fails; the setup is sourced twice before the runner check, which still expectshf ㅗㄹ. The status check fails with 0.2.6 ($?=True exit=3).tests/shells.sh(bash, zsh, fish on Linux CI): the setup is sourced twice; the existingrunners: hf ㅗㄹcheck now covers duplicates.cargo test: the init script is advanced and registers the names once.pwsh -NoProfilewith PSReadLine history pointed at a temp file, codigest's hook from main 9c4cf56: afterhf -yof a mistypedcmd /c exit 3,$?False and$LASTEXITCODE3 with hanfix loaded before the hook, after it, and without it (0.2.6: True in all three). The earlier end-to-end (acodexprobe throughㅗㄹkeeps the terminal, a captured probe throughhf -yis captured under its fixed line, pwsh and Git Bash, both orders): 4/4.local-ci: 79074a8 | cargo test --release --locked 4 passed; tests/shells.ps1 with the built 0.2.7 (ok powershell, ok powershell with codigest) and fails with 0.2.6; ConPTY status probe 3/3 and end-to-end 4/4 above; conventions.py check: 0 findings; sh -n tests/shells.sh | tests/shells.sh (needs util-linux script) and macOS only in CI