Redirection operator `>` should not be hardcoded to files about powershell HOT 6 OPEN

That works for output (or STDOUT), but we don't have 2| for error stream so you have to use 2> which only writes to files currently. Although we have #20381 which would allow redirection to a variable and during that code review I thought of this.

from powershell.

so you have to use 2> which only writes to files currently

If you use *>&1 you can filter for ErrorRecord in the success output. Example.

Yes, but sometimes you want (foo 2>variable:stderr) >variable:stdout

There's also #21565 for those that want tee-object for errors

from powershell.

One can simply pipe through Set-Variable if you want that

PS>  'foo' | Set-Variable 'bar'
PS> echo $bar
foo

No?

from powershell.

so you have to use 2> which only writes to files currently

If you use *>&1 you can filter for ErrorRecord in the success output. Example.

from powershell.

I agree this would be great to have, I currently use the following to capture stdout/stderr as separate vars

$stdout = $null
$stderr = . { my.exe | Set-Variable -Name stdout } 2>&1 | ForEach-Object ToString

The ForEach-Object ToString is only needed for WinPS to capture stderr as a string and not the ErrorRecords in the stream. Having a way to do it directly with redirection would be really nice as I can avoid the above complexity.

from powershell.

@jborean93, the more succinct cross-edition formulation of your code is:

$stdout, [string[]] $stderr = (my.exe 2>&1).Where({ $_ -is [string] }, 'Split')

What #20381 now enables:

my.exe 1> variable:stdout 2> variable:stderr

Alternatively:

$stdout = my.exe 2> variable:stderr

That is, #20381 is sufficient for targeting variables via redirections, via the variable: drive.

The issue at hand is about generalizing this approach, allowing any provider's items as the target.

from powershell.