Repository navigation
Apply Command.MergeMyResults() to a command added as a CommandInfo - #28280
Mitch Richters (mjr4077au) wants to merge 1 commit into
Conversation
`LocalPipeline` builds a command added by name through `Command.CreateCommandProcessor()`, which applies its merge settings, but builds one added as a `CommandInfo` itself without them, so `MergeMyResults("Error", "Output")` on `Write-Error` returned the error as output when it was added by name and left it in the error stream when added through `Get-Command` on both Windows PowerShell 5.1 and PowerShell 7.6.9, so that path now calls `Command.SetMergeSettingsOnCommandProcessor()`, made internal for it, once the parameters are added, as the by-name path does.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
|
Mitch Richters (@mjr4077au) please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
Contributor License AgreementContribution License AgreementThis Contribution License Agreement (“Agreement”) is agreed to by the party signing below (“You”),
|
1 similar comment
|
Mitch Richters (@mjr4077au) please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
Contributor License AgreementContribution License AgreementThis Contribution License Agreement (“Agreement”) is agreed to by the party signing below (“You”),
|
There was a problem hiding this comment.
🟢 Approval recommended
No active review issues are reported for the change aligning stream-merging behavior across command-addition paths.
No open issues 🎉
What changed in this PR
Fixes Command.MergeMyResults() being ignored for commands added as CommandInfo objects, aligning their stream-merging behavior with commands added by name.
Changes:
- Applies merge settings after parameter setup in the
CommandInfopath. - Makes the existing merge-settings helper accessible to
LocalPipeline. - Adds regression tests for error-to-output merging through both command-addition paths.
| File | Description |
|---|---|
test/powershell/engine/Api/PSCommand.Tests.ps1 |
Tests error merging for commands added by name and by CommandInfo. |
src/System.Management.Automation/engine/hostifaces/LocalPipeline.cs |
Applies merge settings to commands constructed from CommandInfo. |
src/System.Management.Automation/engine/hostifaces/Command.cs |
Changes the merge-settings helper from private to internal. |
Review effort: Balanced
|
@microsoft-github-policy-service agree company="Devicie Pty Ltd" |
PR Summary
LocalPipelinebuilds a command added by name throughCommand.CreateCommandProcessor(), which applies the merge settings fromCommand.MergeMyResults(), but builds a command added as aCommandInfoitself and skipped them. That path now callsCommand.SetMergeSettingsOnCommandProcessor(), made internal for it, once the parameters are added, as the by-name path does.PR Context
Seen on Windows PowerShell 5.1 and PowerShell 7.6.9:
Adding
'Write-Error'by name instead returns the error as output.A test covering both ways of adding the command is added to
PSCommand.Tests.ps1. TheCommandInfocase fails onmasterand passes with this change, and theengine/Api,PipelineBehaviour,RedirectionOperator,NativeCommandBytePiping,SplattingandOut-Defaulttests pass.Related: #27674, which uses a command's
CommandInfoinCommand.CreateCommandProcessor(). It touches different lines and doesn't conflict with this change.PR Checklist
.h,.cpp,.cs,.ps1and.psm1files have the correct copyright header🤖 Generated with Claude Code