Related: #6291 and #6360
Note: Unlike the linked issues, the broken behavior described here only affects PowerShell commands, not also native executables.
Steps to reproduce
# Basic function without declared parameters that echoes its arguments via $Args
function Out-Args { $i = 0; $Args | % { 'arg[{0}]: {1}' -f $i++, $_ } }
# Advanced function that binds all arguments via `ValueFromRemainingArguments` and echoes them.
function Out-RemainingArgs { param([parameter(ValueFromRemainingArguments)] $otherArgs) $i = 0; $otherArgs | % { 'arg[{0}]: {1}' -f $i++, $_ } }
# Pass a -<param-nam>:<value> argument that looks like a named parameter, but isn't -
# it is bound anonymously, via $Arg / via `ValueFromRemainingArguments`
Out-Args -foo:bar
'---'
Out-RemainingArgs -foo:bar
Expected behavior
arg[0]: -foo:bar
---
arg[0]: -foo:bar
Actual behavior
arg[0]: -foo:
arg[1]: bar
---
arg[0]: -foo:
arg[1]: bar
That is, the single $Args / ValueFromRemainingArguments-bound argument was unexpectedly broken in two.
Note that, by contrast, the following cases DO work correctly:
-
When passing tokens such as -foo:bar to external programs - because special effort is already being expended to make this case work (which is needed, because initially all such tokens are parsed as if they were named parameters, even if they later turn out not to be - see @BrucePay's comment below.)
-
Had there been a named parameter $foo to bind to, things would have worked as expected (the token would have been recognized as a parameter-name/value pair: the -foo part would have been used to identify the target parameter, and the bar part would have become the parameter variable's value).
Environment data
PowerShell Core v6.0.1 on macOS 10.13.3
PowerShell Core v6.0.1 on Ubuntu 16.04.3 LTS
PowerShell Core v6.0.1 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)
Windows PowerShell v5.1.15063.674 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)
Related: #6291 and #6360
Note: Unlike the linked issues, the broken behavior described here only affects PowerShell commands, not also native executables.
Steps to reproduce
Expected behavior
Actual behavior
That is, the single $Args /
ValueFromRemainingArguments-bound argument was unexpectedly broken in two.Note that, by contrast, the following cases DO work correctly:
When passing tokens such as
-foo:barto external programs - because special effort is already being expended to make this case work (which is needed, because initially all such tokens are parsed as if they were named parameters, even if they later turn out not to be - see @BrucePay's comment below.)$Argsor@Args, the breaking-in-two problem surfaces too - see Parameter parsing/passing: unquoted tokens that look like named arguments with colon as the separator are broken in two when passed indirectly via $Args / @Args #6360Had there been a named parameter
$footo bind to, things would have worked as expected (the token would have been recognized as a parameter-name/value pair: the-foopart would have been used to identify the target parameter, and thebarpart would have become the parameter variable's value).Environment data