- If an EC2 Reserved Instance is not applied or used - Thu, Jan 20 2022
- Midnight Commander remote connect via Shell link (copy files over SSH) and SFTP link using FISH and public key authentication - Mon, Jan 17 2022
- Root login via SSH and SFTP on EC2 instances running Linux - Wed, Jan 12 2022
Last week, the Scripting Guy had a promising headline: “Don’t Learn PowerShell: Use Cmdlets.” The corresponding blog post is an answer to a reader who complained that he now has to “learn command-line stuff like AS400 or VAX.” The Scripting Guy somehow parsed the question incorrectly and came to the conclusion that the reader was reluctant to learn something new, which resulted in this somewhat contradictory headline.
However, I believe the reader complained about the relapse into the computer stone age. Scripting guys often believe that GUI admins are either too lazy to learn PowerShell or just not geeky enough, whereas GUI admins often think CLI admins have been left behind technologically. Well, the world is full of misunderstandings.
Nevertheless, the scripting guy’s blog post is interesting because it is a nice attempt to make PowerShell palatable to a GUI admin. By giving a step-by-step example of how to use PowerShell ISE’s Commands add-on, he demonstrates how you can create a firewall rule with PowerShell—well, without the need to learn PowerShell.
The Commands add-on is indeed a good start for every PowerShell beginner. If the Commands add-on isn’t displayed in PowerShell ISE, you can enable it from the View menu. Essentially, it is identical to the Show-Command cmdlet that you can launch from a PowerShell console. The only difference from Show-Command is that the Commands add-on also allows you to insert the PowerShell command into the script pane. With Show-Command, you can only copy the command to your console or run it right away.
The GUI is helpful for a beginner who has to find a PowerShell cmdlet for a certain task. This distinguishes Show-Command from Get-Command, which requires rudimentary PowerShell skills. You can just start typing in the tool’s Name field, and the tool will find all cmdlets that contain your search term.
You can also restrict your search to certain PowerShell modules using the selector field above the search field. Many of the modules only have a few cmdlets, and it makes sense for a beginner to skim through modules of your work domain. The cmdlet names are often self-explanatory, and you will immediately grasp what you can do with them.
Search in Show-Command
After you click a cmdlet, you will get a list of all available parameters. If a cmdlet belongs to a module that hasn’t been imported, you have to click Show Details first, and Show-Command will then import the module in order to access the cmdlet’s parameters.
Mandatory parameters are marked with a “*” and each parameter set has its own tab. You can use all parameters in a set in one command, that is, if two parameters supported by the cmdlet are not in the same set, you can’t use them together. Some parameter combinations just don’t make sense. With the sets separated on different tabs, you get a good overview of the cmdlet’s different usage scenarios.
Parameter sets in Show-Command
For instance, the Get-AppLockerPolicy cmdlet has three parameter sets: LocalPolicy, DomainPolicy, and EffectivePolicy. The LDAP and Domain parameters can’t be used together with the Local parameter because it doesn’t make sense to query the local and the domain policy in one command.
Below the parameter sets is a link to the Common Parameters. You can use Common Parameters with any cmdlet. A typical example is the ErrorAction parameter that you can use in try/catch blocks. But this is only something for advanced scripting guys. You probably won’t need them in your first GUI-based CLI attempts.
As with cmdlet names, most parameter name meanings are self-explanatory. However, sometimes you will need detailed information about how the cmdlet works. In that case, you simply have to click the blue question mark, and Show-Command or the Commands add-on in PowerShell ISE will access the corresponding PowerShell help file.
The best thing about these GUI tools is that they can save you some typing—a kind of finger exercise that many GUI admins despise as an old-fashioned way of communicating with a computer. Parameters that don’t require an argument can be activated with a click, and you can see the other parameters just as input fields in a GUI.
Once you have “configured” your PowerShell command, I recommend not running it right away and just copying it to your console to see what the command looks like. Cmdlets that modify computer settings have a WhatIf switch at the end of the parameter list, which allows you to preview your changes without applying them to the system.
WhatIf in Show-Command
Show-Command can also be helpful for advanced CLI admins who already have finger arthritis and want to avoid typing or who just want a quick graphical overview of a cmdlet’s supported parameters. If you already know which cmdlet you want to use, you can simply run Show-Command with the cmdlet that you need for your command:
Show-Command will automatically import the module if you haven’t yet added it to your current session.
Whereas Show-Command and PowerShell ISE’s Commands add-on are certainly useful tools for GUI-minded admins and PowerShell beginners, I doubt that they allow you to avoid learning PowerShell. Using PowerShell is not just about using cmdlets. If you want to “automate” with PowerShell, you need to learn many different programming language concepts, such as loops, arrays, functions, and comparison operators.