Fix accidental wrapping of scalar Write-Output input #5552
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
when
-NoEnumerateis used. Fixes #5122.Note: This PR is a compromise that attempts to reconcile @PetSerAl's conceptually cleaner, but abandoned #5123 with the conflicting changes in #2038.
#2038 should never have happened and continues to cause problems.
Specifically, the implications of this PR are:
a single scalar input object is now also passed through when
-NoEnumerateis specified, as is desirableWrite-Output -NoEnumerate 1is now indistinguishable fromWrite-Output -NoEnumerate -InputObject ([System.Collections.Generic.List[object]]::new((, 1)))by changing the
-InputObjectparameter type from[psobject[]to[object], multi-argument inputs passed without explicit use of-InputObjectare now passed through as a[List[object]]instance when using-NoEnumerate, which is an unfortunate side effect of howValueFromRemainingArgumentsarguments are reported - see A ValueFromRemainingArguments parameter by default invariably receives a [List[object]] collection rather than a scalar / PowerShell array ([object[]]), as appropriate #4625.