Repository navigation
CommandInvocationIntrinsics.InvokeScript bind arguments to $input instead of $args #4923
Description
public Collection<PSObject> InvokeScript(string script, params object[] args)
{
return InvokeScript(script, true, PipelineResultTypes.None, args);
}Pass args parameter into input parameter of called function, thus mixing them up.
Steps to reproduce
$ExecutionContext.SessionState.InvokeCommand.InvokeScript('"`$args:($args); `$input:($input)"', 1, 2, 3)Expected behavior
$args:(1 2 3); $input:()
Actual behavior
$args:(); $input:(1 2 3)
Environment data
Tested in v2.0 and v5.1.15063.608
Activity
SteveL-MSFT commentedon Sep 30, 2017
Good find! This looks like just a mistake in the code.
lzybkr commentedon Oct 3, 2017
@PowerShell/powershell-committee - Adding
Breaking-Changebecause it is. Were call sites reviewed to evaluate impact? On the surface, it feels low risk, but it's hard to evaluate without knowing where the api is actually used.iSazonov commentedon Oct 4, 2017
Reopen to track previous question.
SteveL-MSFT commentedon Oct 4, 2017
Jason Shirk (@lzybkr) in our code, most calls are using InvokeScript(script) and the rest don't call this specific overload. Unfortunately,
InvokeScriptis a pretty common method name so a search on GitHub returns many results, but most I looked at briefly on the first 4 pages aren't PowerShell related.lzybkr commentedon Oct 4, 2017
You need to add an extension when searching - much more useful results:
https://github.com/search?utf8=%E2%9C%93&q=InvokeScript+extension%3Aps1&type=Code
https://github.com/search?utf8=%E2%9C%93&q=InvokeScript+extension%3Apsm1&type=Code
I see many calls to what I think is the same api (mostly in psm1 files), but the parameter in question is always
$null. I only sampled the results though.SteveL-MSFT commentedon Oct 4, 2017
Jason Shirk (@lzybkr) As best I could tell based on your search results, the Reflection module uses InvokeScript() passing in input/args. From my basic test, it appears to work fine with the change. Are you ok to close this?
lzybkr commentedon Oct 5, 2017
That module doesn't call the overload that was fixed, so it's not affected by the change.
I'm fine with closing as long as the change is documented properly.
iSazonov commentedon Oct 5, 2017
Steve Lee (@SteveL-MSFT) Could you please add this in the PR #4963 description (it is very short) for future documentation?
SteveL-MSFT commentedon Oct 5, 2017
Ilya (@iSazonov) I've already added the
documentation neededlabel to the PRiSazonov commentedon Oct 5, 2017
Yes, I see. I meant that the description very short - don't clear that we should document.
SteveL-MSFT commentedon Oct 5, 2017
I think it's clear enough when my team goes through the
documentation neededitems later.argswas being passed to theinputparameter incorrectly.MartinGC94 commentedon Aug 20, 2025
Just ran into this while making a PowerShell module that is supposed to work in 5.1 and 7+ (please start shipping 7 with Windows). The workaround I came up with was to just add this to the snippet I run:
$FixedInput = if ($args.Count -ne 0) {$args} else {$input}this also has the positive side effect of enumerating$input.