This blog post applies to the Windows PowerShell Version 3.0.
Problem: How can I find out what cmdlets are available for a given task?
Finding cmdlets in the traditional way
If you know the basics of get-command, feel free to skip this section.
If you are searching for a cmdlet to add a printer, you could star with something like:
PS C:\Users\mspuser> get-command *printer*
CommandType Name ModuleName
----------- ---- ----------
Function Add-Printer PrintManagement
Function Add-PrinterDriver PrintManagement
Function Add-PrinterPort PrintManagement
Function Get-Printer PrintManagement
Function Get-PrinterDriver PrintManagement
Function Get-PrinterPort PrintManagement
Function Get-PrinterProperty PrintManagement
Function Remove-Printer PrintManagement
Function Remove-PrinterDriver PrintManagement
Function Remove-PrinterPort PrintManagement
Function Rename-Printer PrintManagement
Function Set-Printer PrintManagement
Function Set-PrinterProperty PrintManagement
Cmdlet Out-Printer Microsoft.PowerShell.Utility
Notice the choice of the noun “printer”, as opposed to the verb “add”. “Add” could be adding anything, so reducing the scope to “printer” allows for a more precise initial search.
For this simple case of adding a printer, it is very possible that the first guess would be “add-printer”, but the verb is not always as simple to guess. Also, it is nice to look around and see what other printer related cmdlets are available. Chances are one task leads to another and we will need another cmdlet soon like get-printer to see that the printer we added is there.
The first * in *printer* allows finding cmdlets with any verb or noun prefix. By “noun prefix” I mean the cmdlet developers could have called them SystemPrinters, PSPrinters, or other name. The second * allows for any noun suffix like “Driver” and “Property” in the list above.
After looking at the list, we might conclude that we are not interested in “PrinterDriver” or “PrinterPort” so that the second * made our search less precise. We can issue the command again without the second * for less results but, for the generic case of searching for any other noun, using both * will guarantee we will not miss anything.
After you found the cmdlet, you can explorer it a bit further with one of the following:
Finding cmdlets with show-cmdlet
We saw in Running show-command for a cmdlet, how to use show-command for a specific cmdlet. If you run just “show-command” this is what you get:
- A “Module” is a set of cmdlets for a given domain. In this window you can see cmdlets from all modules, but you might filter the results to a specific module, in the “Modules” drop down.
If then you type “printer” under Name, you have:
Notice that *printer* is implicit. If the cmdlet contains printer, you will see it.
If you had typed printers, you would see the same list, because the search results also include the singular form of what you typed.
When you click the Add-Printer cmdlet you get the window on the left below, and after you click “Show-Details” you get the window on the right:
Show-command allows for a simpler way to find a cmdlet and then to get more details about it such as parameters and help (question mark button). It is a simpler route from thinking about a task to finding out how to accomplish it.
- The “Add-Printer” section of the window is the same we would see if we had typed “show-command add-printer” and that part is explored a bit more in Running show-command for a cmdlet.
- The same window as the one displayed for “show-command” is also embedded in “PowerShell ISE” by default and can be seen in the “View - Show Command Add-on” menu when not present. To start ISE, type ise in a PowerShell console and press Enter.
- If the cmdlet module is already imported, you will not see the “Show Details” button.
- For a cmdlet belonging to a module that was not yet imported, we had 2 alternatives: starting to load the module as soon as Add-Printer is selected, or using the intermediary “Show Details” text you see on the left. We decided for the intermediate step to give the user a chance to understand a module is going to be imported and explicitly choose to do that. We were not comfortable with the idea of selecting list items with mouse or keyboard resulting in modules being loaded implicitly.
Lucio Silveira [MSFT]