-
Notifications
You must be signed in to change notification settings - Fork 7.1k
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
Redirection operator >
should not be hardcoded to files
#23794
Comments
One can simply pipe through Set-Variable if you want that
No? |
That works for output (or STDOUT), but we don't have |
If you use |
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 |
@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 The issue at hand is about generalizing this approach, allowing any provider's items as the target. |
Summary of the new feature / enhancement
Currently,
>
will internally callOut-File
. Instead, it should probably callOut-Provider
(or something like that) so that any provider can participate:1 > variable:a
.Proposed technical implementation details (optional)
If a provider path isn't provided, default to filesystem
The text was updated successfully, but these errors were encountered: