{"id":9781,"date":"2012-04-22T00:01:00","date_gmt":"2012-04-22T00:01:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/2012\/04\/22\/the-problem-with-powershell-positional-parameters\/"},"modified":"2012-04-22T00:01:00","modified_gmt":"2012-04-22T00:01:00","slug":"the-problem-with-powershell-positional-parameters","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/the-problem-with-powershell-positional-parameters\/","title":{"rendered":"The Problem with PowerShell Positional Parameters"},"content":{"rendered":"

Summary<\/b>: In this blog, Microsoft Scripting Guy, Ed Wilson, talks about problems that can arise when using Windows PowerShell positional parameters.\nMicrosoft Scripting Guy, Ed Wilson, is here. Today is the final day of judging for the 2012 Scripting Games. The judges have made a magnificent effort these last few days to get the final scripts graded. The leaderboard has changed on a minute-by-minute basis for the last several days, and I know from twitter that many of you have been following the leaderboard more closely than University of Kentucky basketball fans followed the NCAA Final Four Tournament games.\nIn yesterday’s blog, When You Should Use PowerShell Aliases<\/a>, <\/i>I discussed the problems that indiscriminate alias usage creates.\nOne of the main problems with using Windows PowerShell aliases, even at the Windows PowerShell console, is that the code is much less readable. The same problem exists with positional parameters, parameter aliases, and partial parameters.<\/p>\n

Understanding positional parameters<\/h2>\n

Positional parameters make Windows PowerShell commands shorter because you do not have to do as much typing, and some of the parameter names are rather long. But the problem is that unless you really know what a cmdlet does, and how it does it, you might not know what is actually going on. An example is the following command.<\/p>\n

S C:> copy c:1 c:3\nSo what does this command do? Well, it might copy the contents of the c:3 folder to the c:1 folder. Or it might copy the contents of the c:1 folder to the c:3 folder. For that matter, what is the copy command? The copy command is an alias for the Copy-Item cmdlet. Now, what is the first parameter? Is the parameter name source original, path, target, destination, or what? As a matter of fact, the first parameter is path. The second parameter is destination. To find this sort of information you need to use the Get-Help<\/b> cmdlet with the Full <\/i>switch. Each parameter entry includes information that states if the parameter is required, positional, or whatever. The following output displays the Path <\/i>and the Destination <\/i>parameter information.<\/p>\n

-Path <string[]><\/p>\n

     Specifies the path to the items to copy.<\/p>\n

 <\/p>\n

     Required?                    true<\/p>\n

     Position?                    1<\/p>\n

     Default value<\/p>\n

     Accept pipeline input?       true (ByValue, ByPropertyName)<\/p>\n

     Accept wildcard characters?  False<\/p>\n

-Destination <string><\/p>\n

    Specifies the path to the location where the items are to be copied.<\/p>\n

 <\/p>\n

    Required?                    false<\/p>\n

    Position?                    2<\/p>\n

    Default value<\/p>\n

    Accept pipeline input?       true (ByPropertyName)<\/p>\n

    Accept wildcard characters?  false<\/p>\n

Understanding partial parameters<\/h2>\n

Another way of speeding up working with parameters is to use partial parameter names. For example, many cmdlets have a parameter named ComputerName. <\/i>Now, this is a lot of typing. It is especially unfortunate because the Get-WmiObject<\/b> cmdlet does not accept ComputerName <\/i>positionally. Therefore, the following command fails.<\/p>\n

PS C:> gwmi win32_bios localhost<\/p>\n

Get-WmiObject : Invalid query<\/p>\n

At line:1 char:5<\/p>\n

+ gwmi <<<<  win32_bios localhost<\/p>\n

    + CategoryInfo          : InvalidOperation: (:) [Get-WmiObject], ManagementExce<\/p>\n

   ption<\/p>\n

    + FullyQualifiedErrorId : GetWMIManagementException,Microsoft.PowerShell.Comman<\/p>\n

   ds.GetWmiObjectCommand\nThis does not mean that you are limited to typing the entire ComputerName <\/i>parameter name each time you want to connect to a remote computer. You only need to type enough of the parameter so that it will distinguish it from other parameters that also start with the letter C<\/b>.<\/i> One easy way to see what will work is to simply run the command and look at the error message. In the following output, you can see that there are three parameters on the Get-WmiObject<\/b> cmdlet that begin with the letter C<\/b>. The first is Class, <\/i>the second one is Credential, <\/i>and the last parameter is ComputerName. <\/i><\/p>\n

PS C:> gwmi win32_bios -c localhost<\/p>\n

Get-WmiObject : Parameter cannot be processed because the parameter name ‘c’ is ambi<\/p>\n

guous. Possible matches include: -Class -Credential -ComputerName.<\/p>\n

At line:1 char:5<\/p>\n

+ gwmi <<<<  win32_bios -c localhost<\/p>\n

    + CategoryInfo          : InvalidArgument: (:) [Get-WmiObject], ParameterBindin<\/p>\n

   gException<\/p>\n

    + FullyQualifiedErrorId : AmbiguousParameter,Microsoft.PowerShell.Commands.GetW<\/p>\n

   miObjectCommand\nBased on the error message, you can safely use co <\/i>as the partial parameter for ComputerName. <\/i>This technique is shown here.<\/p>\n

PS C:> gwmi win32_bios -co localhost<\/p>\n

SMBIOSBIOSVersion : 8BET47WW (1.27 )<\/p>\n

Manufacturer      : LENOVO<\/p>\n

Name              : Default System BIOS<\/p>\n

SerialNumber      : R9FPY3P<\/p>\n

Version           : LENOVO – 1270\nConsider the following issues if you use partial parameter completion:<\/p>\n