New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
exit status 0
on syntax errors, when reading scrip from stdin
#21784
Comments
The good news is I can just refer back to 21808 for much of this. My explanations often start with PowerShell is not a UNIX shell. UNIX programs are pipe/stream based, PowerShell is record based. Two more details are significant
Lets see this in action
with the result
What you see is that none of the first record was executed. The assignment of $ErrorActionPreference never happened. |
Fundamentally, a parser error cannot be handled with runtime constructs such as It is the statement-by-statement, REPL-like processing exhibited by |
@rhubarb-geek-nz Well I guess my reply would be mostly what I've wrote over in the other ticket, i.e. that it's at least undocumented, that If there'd really be a need for a mode of that semi-interactive parsing, it would IMO be better to have separate option for that and not for @mklement0 My main point here wasn't about the |
Yes. That's why I said that what you've uncovered should indeed be considered a bug. |
The Interactive WG discussed this. The feature |
@philcerf, to bring closure to the specific aspect of the As it turns out, the observed behavior is actually consistent with the pseudo-interactive, REPL-like behavior (which has just been declared to be by design), and the reason is now mentioned in the doc-update PR that @sdwheeler has since submitted:
A simple example: @'
# If you uncomment the following statement, $LASTEXITCODE will be 1, because it is then
# this command's $? value that determines the exit code.
# 1 / 0
& {
1 / # This syntactically broken command has NO impact on the exit code.
}
'@ | pwsh -NoProfile -Command -; $LASTEXITCODE # -> 0(!) It follows that if you use the workaround to make While the While this wouldn't be much of an improvement in a true interactive session, it would help in the |
TBH, I kinda stopped following these issues a bit, because the general way they seem to be dealt with is: I mean for me it's not really a big problem, since I simply pass my commands now as a multiline strings argument to But I guess more people will fall into the traps involved when commands are read (non-interactively) from stdin with a behaviour that probably makes no sense in any situation. Anyway, thanks for the workaround suggestions, but I rather go by my multiline string argument, because there's always the danger that there's more weird behaviour with the semi-interactive mode which no one can reasonably expect - I mean I found already a handful in just a few days. Thanks, |
This issue has been marked as by-design and has not had any activity for 1 day. It has been closed for housekeeping purposes. |
📣 Hey @philcerf, how did we do? We would love to hear your feedback with the link below! 🗣️ 🔗 https://aka.ms/PSRepoFeedback |
Prerequisites
Steps to reproduce
Hey.
This also seems to go back to the days of
powershell.exe
and seems particular disturbing.When running a script with a deliberate syntax error (the
-EQfoo
):like this:
The exit status returned by PowerShell is non-zero (as it should be):
When running it however via stdin like so:
The exit status is
0
:Expected behavior
use non-zero exit status on syntax error, even when command is read from stdin
Actual behavior
uses 0 as exit status
Error details
No response
Environment data
N/A
Visuals
No response
The text was updated successfully, but these errors were encountered: