^{Closely related to #3996 and #11133}

The current behavior of calling external programs without stderr redirection is being discussed in the linked issue.

Either way, simply adding 2>$null or 2>&1 - indeed, any redirection of stderr (2>...) - to a command shouldn't fundamentally change its error-handling behavior.

Note that when a host other than the console host is involved (e.g., when in the ISE or when remoting), the difference described below does not occur, but the behavior is fundamentally different (and presumably undesired - see #3996).

Note:

• Even though the repro steps use external programs, PowerShell commands are equally affected (e.g., & { $ErrorActionPreference = 'stop'; Get-Item NosuchFile 2>$null } unexpectedly produces an error, whereas -ErrorAction SilentlyContinue would not).

• Similarly, using 2> with an actual file as the target is also affected (e.g., & { $ErrorActionPreference = 'stop'; whoami badarg 2>stderr.txt } aborts, and stderr.txt is empty).

Steps to reproduce

On Unix, replace cmd /c with sh -c.

& { $ErrorActionPreference = 'stop'; cmd /c nosuch; $? }
& { $ErrorActionPreference = 'stop'; cmd /c nosuch 2>$null; $? }

Expected behavior

Both commands should fundamentally behave the same, which, based on the current default behavior in the console, is to not report an error, with stderr output passed through in the 1st command and stderr output getting suppressed in the other.

'nosuch' is not recognized as an internal or external command,
operable program or batch file.
False

Actual behavior

• The 1st command behaves as expected.

'nosuch' is not recognized as an internal or external command,
operable program or batch file.
False

• The 2nd command terminates the statement and outputs the first stderr line only in red (note that in Windows PowerShell you get the usual, full error output):

'nosuch' is not recognized as an internal or external command,

The 2nd half of the error message, operable program or batch file., is missing.

Presumably, this happens because:

• as usual, each individual stderr line becomes its own [System.Management.Automation.ErrorRecord] instance,
• and the very 1st line by itself triggers termination of the statement (in this particular case, the cmd error message happens to span 2 lines).

Note that any 2> redirection causes the symptom, such as 2>&1 or 2>err.txt.

Seemingly, the following happens:

• Despite redirection of the error stream, the stderr lines are apparently still passing through it, as evidenced by them showing up in $Error afterwards.

• With $ErrorActionPreference = 'stop' in effect, anything getting written to PowerShell's error stream instantly triggers a function/script-terminating error.

Again, note that without a redirection, stderr lines neither show up in $Error nor do they cause the script to be terminated based on $ErrorActionPreference = 'stop'.

Environment data

PowerShell Core v6.0.0-beta.4 on macOS 10.12.5
PowerShell Core v6.0.0-beta.4 on Ubuntu 16.04.2 LTS
PowerShell Core v6.0.0-beta.4 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)
Windows PowerShell v5.1.15063.413 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)