New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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 #6360
Comments
@mklement0 As i describe in the comments in #6292, these are named PowerShell arguments. Always. Parameter binding is done long after the compile is complete. Now in the compiled AST, the token for One way to fix this is to propagate the "NoSpace" token property into metadata on the corresponding string value. The |
#6492 (since closed as a duplicate) shows that splatting Supporting that scenario is presumably even trickier, because the expectation here is that the named parameters are passed through as-is, with their original types. Here's a simplified repro: function b {
Param
(
[Switch] $p1,
[int] $p2,
$rest
)
"`$p1: [$p1]"
"`$p2: [$p2]"
"`$rest: [$rest]"
}
& { b @args } -p1:$false 666 $p1: [True] # `-p1:` was interpreted as just `-p1`
$p2: [0] # `$false`, as a separate argument, was coerced to [int] 0
$rest: [666] # what was meant to be the 2nd argument was passed as the 3rd The workaround - and preferable solution to begin with - is to define the same |
I just spent the past week or so wrestling with this issue. After tracking it down to forced switch parameter values (such as For reference, this is the test I created to show the bug. Saw it on a Server 2016 machine with Powershell 7 Preview 1, as well as a Server 2012 R2 machine with Powershell 5.1. function foo
{
param(
[switch]$testArg = $false
)
write-host "Test arg value: '$testArg'"
}
function bar
{
foo @Args
}
$testSplat = @{
testArg = $false
}
write-host "#### Foo tests ####"
foo
foo -testArg:$true
foo -testArg:$false
foo @testSplat
write-host "#### Bar tests ####"
bar
bar -testArg:$true
bar -testArg:$false
bar @testSplat |
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. |
1 similar comment
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. |
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. |
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes. |
Related: #6291, #6292, and #4624
Following up from #6292 (comment):
Note: The tokens in question, such as
-foo:bar
, look like named PowerShell arguments (and, behind the scenes, are initially always parsed as such - see @BrucePay's comment below), but should be passed through as-is (except for possibly expanding the string) when calling external programs.Tokens that happen to look like
-foo.bar
suffer a similar fate (see #6291).This already works as expected with direct argument passing (e.g.,
echoArgs -foo:bar
passes-foo:bar
as a single argument), but not when passing
$Args
/ splatting it (@Args
).Note: The problem is fundamental to the use of
$Args
/@Args
and, while perhaps less common, also affects its use when calling PowerShell-native commands - see comment below.Steps to reproduce
Run on macOS or Linux.
Expected behavior
Actual behavior
The arguments are unexpectedly broken in two. See linked comment for background.
Environment data
The text was updated successfully, but these errors were encountered: