Change $ErrorActionPreference to not affect stderr output

[SteveL-MSFT]

PR Summary

Based on @PowerShell/powershell-committee discussion, we agreed that stderr should not be treated as an ErrorRecord as many native commands use that as an alternate stream from stdout and it does not signify an error (like verbose or progress information). Stderr output is still wrapped as ErrorRecords, but the runtime no longer applies $ErrorActionPreference if the ErrorRecord comes from a native command. The diff makes the change look bigger than it is, but it's simply wrapping existing code that applies $ErrorActionPreference and writing to $Error to not apply if the ErrorRecord is simply wrapping stderr.

Updated TestExe to have a switch to write output to stderr.

PR Context

Fix #3996

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• Breaking changes
  • None
  • OR
  • Experimental feature(s) needed
    • Experimental feature name(s): PSNotApplyErrorActionToStderr
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed: $ErrorActionPreference doesn't affect stderr output for native commands MicrosoftDocs/PowerShell-Docs#6466
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
• Tooling
  • I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
  • OR
  • I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:
    • Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
    • Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
    • Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
    • Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

[SteveL-MSFT]

CodeFactor is an existing issue complaining about the complexity of the method that was updated. Not going to change in this PR.

[felixfbecker]

Can the stderr ErrorRecords still be captured with -ErrorVariable?

[daxian-dbw]

@felixfbecker No it cannot be captured by -ErrorVariable after this change. I believe this is intentional but @SteveL-MSFT can clarify it.

[felixfbecker]

Basically my question is: How can a user still run a native command, get the stdout output if it was successful, but also get access to the stderr output if it was unsuccessful? That's a very important use case.
Maybe this is solved in conjunction with #3415, e.g. the stderr output would be available on the exception object?

[daxian-dbw]

How can a user still run a native command, get the stdout output if it was successful, but also get access to the stderr output if it was unsuccessful? That's a very important use case.

I'm curious how this is done today in console before this PR? In console, unless we redirect the stderr stream, the message written to stderr from the native command will always handled by the console (print on console).

Maybe this is solved in conjunction with #3415, e.g. the stderr output would be available on the exception object?

The discussion on it so far is that the exception only has the exit code, not the content from stderr.
The idea is: many native commands write to stderr not as error messages, but an alternate stream for additional information that doesn't make sense to write to stdout. This includes content such as verbose or progress output.
But that can be further discussed in #3415.

[ghost]

🎉v7.1.0-preview.6 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes