Repository navigation
StdErr is wrapped as ErrorRecord producing undesired effects #3813
Description
Activity
- added this to the milestone
on May 18, 2017 I looked into that, the gist of the problem is the following
In GenerateOutOfBandData we are receiving View for error record, which is registered here.
If we receive a View, it's automatically will be passed thru out format system, either as a complex object or as a list. That would force the screen width formatting on it.There are few ways we can go about it that come to my mind:
- Put a special case hack 👎 - easy, but ugly
- Consider to take away the formatting break logic from ComplexViewEntry maybe?
- Subclass the NativeErrorRecord from ErrorRecord so we can have more granular control and put less ugly special case hack.
Looking for opinions
Seems like option 3 is best. Whenever PowerShell works with native cmds we should keep the data raw for perf and compat reasons.
Can the problem be in other streams?
Can the problem will be resolved by native pipes #1908?I can't reproduce the bug with cmd.exe instead of python 😕
Ilya (@iSazonov) you may need to make your window smaller or output larger to observe it (essentially larger then 1 width of your window)
Here is another repro with just powershell
PS C:\dev\platyPS> powershell -Command '1..1000 | % { [System.Console]::Error.Write("1") }' *> 1 PS C:\dev\platyPS> cat 1 | measure Count : 12 Average : Sum : Maximum : Minimum : Property :Thanks for the repo!
I see that the formatting work well - we hit that line.
If we remove the view the problem persists.
So the problem is somewhere else.Maybe be the same problem #1491
I see that the formatting work well
Let me elaborate the problem.
If
view != nullhereWe are using ViewGenerator and it will apply logic for the window width.
What we want is something like GenerateOutOfBandObjectAsToString(so)
Thanks for clarify!
Can we add new parameter in the view?
CustomControl.Create(outOfBand: true, MaxWidth: Int.MaxValue)- modified the milestones: ,
on Oct 15, 2017 - changed the title
[-]Redirecting stderr adds extra-line breaks[/-][+]StdErr is wrapped as ErrorRecord producing undesired effects[/+]on Oct 19, 2017 Steve Lee (@SteveL-MSFT) Is this issue already fixed? The PR #5190 hasn't been merged, but I cannot repro with sergei (@vors)'s windows repro step on RC build:
PS:1> pwsh -Command '1..1000 | % { [System.Console]::Error.Write("1") }' *> 1 PS:2> cat 1 | measure Count : 1 Average : Sum : Maximum : Minimum : Property :
Dongbo Wang (@daxian-dbw) the original issue where line breaks were added at window width has been fixed. stderr is still being wrapped as error record, but it gets unwrapped I believe so it's just an optimization. I think we can close this since the original user facing issue is resolved.
Oh nice, didn't see that coming 💃
Steps to reproduce
Run some executable that outputs a long line to stderr and redirect it.
For example
Real-life scenario that's highly impacted by that problem is searching in the logs.
When log file can be arbitrary split on the search tokens, you cannot reliable find anything in the logs.
Expected behavior
One line in the file
1Actual behavior
Several lines in the output file.
Compare it with the redirection of
stdoutwhich works as expected.Environment data