Repository navigation
CLI: -OutputFormat XML situationally produces broken XML (CLIXML) #12489
Description
The CLI's -OutputFormat Xml (-o Xml / -of Xml) parameter produces CLIXML output that can later be read with Import-CliXml, for instance.
If a -Command / -c command string / a *.ps1 script file passed to -File writes to multiple streams, the output XML text is broken in two (possibly related) ways:
-
The single magic
#< CLIXMLcomment that is usually on the first line only is doubled (that is, the 2nd line contains the same comment, with only the 3rd line containing the XML). -
A 2nd top-level
<Objs>root element appears, seemingly covering the non-success streams separately, which results in broken XML as well as a loss of the ordering of output objects.
As an aside: it seems that host output is captured as success-stream output (S="Output") rather than information-stream output (S="information").
Is this by (historical) design, retained for backward compatibility?
Steps to reproduce
{
$ErrorActionPreference = 'Stop'
pwsh -o xml -noprofile -command 'Write-Output output!; Write-Verbose -vb verbose!' |
Write-Output
} | Should -not -ThrowExpected behavior
The test should succeed - no errors should occur.
Note that the test relies on the fact that PowerShell automatically deserializes CLIXML text when you send it through the pipeline, so that Write-Output outputs the deserialized ("rehydrated") output objects.
Actual behavior
The following error occurs:
Expected no exception to be thrown, but an exception
"Cannot process the XML from the 'Output' stream of '/.../pwsh':
Data at the root level is invalid. Line 1, position 1." was
thrown from line:1 char:36 ...
If you want to examine the actual XML, run the following on Unix:
sh -c 'pwsh -o xml -noprofile -command ''Write-Output output!; Write-Verbose -vb verbose!'' > out.xml'You'll see the following content in out.xml - note the doubled comment line and the presence of two root elements (broken XML):
#< CLIXML
#< CLIXML
<Objs Version="1.1.0.1" xmlns="http://schemas.microsoft.com/powershell/2004/04">
<S S="Output">
output!
</S>
</Objs>
<Objs Version="1.1.0.1" xmlns="http://schemas.microsoft.com/powershell/2004/04">
<S S="verbose">
verbose!
</S>
</Objs>Environment data
PowerShell Core 7.1.0-preview.2
Activity
[-]CLI: -OutputFormat XML situationally produces broken XML[/-][+]CLI: -OutputFormat XML situationally produces broken XML (CLIXML)[/+]vexx32 commentedon Apr 25, 2020
I've seen this turn up in a few places, but wasn't sure what exactly was causing it. Thanks for the detailed investigation as always! 😊 💖
Jaykul commentedon Mar 31, 2022
Another very baffling side-effect of this, is when you get only error output. So for instance:
You expect a
#< CLIXMLheader to mean the output gets converted to objects and you'll capture it in$Result, but in this case you get a spew of XML because the command is not found... It might take you a while to realize thatpwsh(orPowerShell, because this has always been like this) has produced all this output on stderr, and the hosting instance doesn't deserialize stderr output, even if it does have the CLIXML header.NOTE: You can work around this by redirecting the other stream to stdout ... but then it's all co-mingled...
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 23, 2023
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.