Fishing for PowerShell: Leveraging Get-Command and Show-Command
During my recent summer vacation, I spent some time fishing with my son, who’s an avid fisherman and takes it much more seriously than I do. As we meandered around the lake on the boat, I started thinking that fishing is as much hunting for the right spot or some clue as to where the fish might be. Granted, knowing where to look for these clues takes a lot of experience. And because I’m never truly on vacation, I started thinking about how this might apply to someone learning PowerShell. If you want to know where the fish are, you need to know where to look. Fortunately, PowerShell has a few spots where you can find answers, and I’m happy to share them.
The first place you should stop is the Get-Command cmdlet. Not sure what command to run to get event logs? Take advantage of Get-Command and its support for wildcards. I’m not saying you will get what you need on the first attempt.
You might try this:
If you try that, then you'll see a lot of results. Don't give up, let's try again.
Your results might vary depending on what modules you have installed. You can also limit your search by getting commands by noun. You can also use wildcards to search for different nouns. Likewise, you can get commands that use a specific verb. If you notice from the screenshots or your own use of Get-Command, you'll see that it finds all types of executables. You can limit the search to a specific type.
And perhaps my favorite use of Get-Command is to see what commands are packed away inside a module or snapin. You can also use the same parameters that I showed you earlier to fine tune the results. You can also use this with snap-ins, even with the –module parameter. Make sure to add the snap-in first.
Windows PowerShell's Show-CommandRelated to Get-Command is Show-Command. Where the former will tell you where a command comes from, the latter will help you figure out how to use it. You have probably seen this in the PowerShell ISE, which I'll talk about in a moment. Let's say you've looked at help for a cmdlet like Get-VMSnapshot: Let's run Show-Command:
You should get a pop-up like this: Each of the tabs, e.g., VMName, corresponds to a different parameter set. You can click on the different tabs to see the different parameter options. Parameter names with an asterisk are required. I also like the drop-down menus for some parameters. I can go ahead and fill out the form. If I click Copy, the final command will be copied to the Windows clipboard. In this case, I will end up with this command:
If I click Run, PowerShell executes the command and closes the dialog box. If you run Show-Command, you'll notice that you won't get your prompt back until the dialog box is dismissed.
Using Show-Command in the PowerShell ISEIn the PowerShell ISE, the Show-Command panel is displayed by default. If you've closed it, you can re-open it from the menu Here, the display is a bit different in that you can search for a cmdlet from a given module. You can also start typing a command name. In the ISE, you will see this message if the module has not been loaded: Go ahead and click "Show Details" to import the module. In the regular console, PowerShell will automatically import the module. Now I have a form I can fill out. Here's the tricky part. If I click Run, PowerShell will execute the finished command in the PowerShell ISE. If I click Insert, PowerShell will insert it into the command window. I can also click Copy and then paste it anywhere I want, including the script pane in the ISE. Here's my full command:
Personally, I'd love for an Insert command that lets you place the command into the script pane. It would also be handy if there's an option to use splatting. But regardless, the Show-Command tool makes it easy to discover just what you need. I have a few more PowerShell fishing tips, which I'll save for next time.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.