exit status 0 on syntax errors, when reading scrip from stdin

[philcerf]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.
• Refer to the FAQ.
• Refer to Differences between Windows PowerShell 5.1 and PowerShell.

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):

$ErrorActionPreference = "Stop"; try{ $null -EQfoo $null} catch {exit 44}

like this:

$ pwsh -NonInteractive -NoProfile -Command '$ErrorActionPreference = "Stop"; try{ $null -EQfoo $null} catch {exit 44}' ; echo exit status: $?

The exit status returned by PowerShell is non-zero (as it should be):

ParserError: 
Line |
   1 |  $ErrorActionPreference = "Stop"; try{ $null -EQfoo $null} catch {exit …
     |                                              ~~~~~~
     | Unexpected token '-EQfoo' in expression or statement.
exit status: 1

When running it however via stdin like so:

$ { pwsh -NonInteractive -NoProfile -Command - <<'END'
$ErrorActionPreference = "Stop"; try{ $null -EQfoo $null} catch {exit 44}

END
} ; echo exit status: $?

The exit status is 0:

ParserError: 
Line |
   1 |  $ErrorActionPreference = "Stop"; try{ $null -EQfoo $null} catch {exit …
     |                                              ~~~~~~
     | Unexpected token '-EQfoo' in expression or statement.
exit status: 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

[rhubarb-geek-nz]

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

• in record processing, the failure of one record does not automatically mean abort or fail the following records, each is treated on its own merits
• PowerShell does not parse character by character looking for ends of statements then executing them, then going back for more. It is not a UNIX shell, it is record based and attempts to parse the whole record. If that parsing fails then none of the record is executed.

Lets see this in action

pwsh -NonInteractive -NoProfile -Command '-' <<'END'
$ErrorActionPreference = "Stop"; try{ $null -EQfoo $null} catch {exit 44}
$ErrorActionPreference
END

with the result

ParserError:
Line |
   1 |  $ErrorActionPreference = "Stop"; try{ $null -EQfoo $null} catch {exit …
     |                                              ~~~~~~
     | Unexpected token '-EQfoo' in expression or statement.
Continue

What you see is that none of the first record was executed. The assignment of $ErrorActionPreference never happened.
So that record failed and on to the next record which shows the current state of $ErrorActionPreference.

[mklement0]

Fundamentally, a parser error cannot be handled with runtime constructs such as $ErrorActionPreference = "Stop" and try / catch.

It is the statement-by-statement, REPL-like processing exhibited by -Command - that isolates a parser error to a given statement, but the fact that a parser error in the last statement doesn't result in a nonzero exit code should indeed be considered a bug, as argued in detail in #21808 (comment)

[philcerf]

@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 - for -Command and -File make them behave completely differently than with values other than -... but more practically spoken: it seems not so good design with, to have a single option, e.g. -Command behave so dramatically different just by changing the source of the data.

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 -Command which behaves just as expected with real commands given.

@mklement0 My main point here wasn't about the try not working (which I think is obvious in case of a syntax error), it was about 0 being returned despite the syntax error... so a caller has no chance of knowing that it didn't work.

[mklement0]

so a caller has no chance of knowing that it didn't work.

Yes. That's why I said that what you've uncovered should indeed be considered a bug.