Practical PowerShell Questions
A free content preview
Note: This content was originally published for paid subscribers to "Behind the PowerShell Pipeline". I'm republishing an excerpt here for free subscribers as sample content that paid subscribers are receiving.
I’m assuming most of my readers have been using PowerShell for a while and most likely consider themselves quite adept. You’ve achieved a reasonable degree of mastery over the PowerShell language. This article focuses on where you apply your PowerShell skills and how.
Location, Location, Location
Much like the real estate adage, where you apply your PowerShell skills is as crucial as the commands you write. I believe there is a difference in how you want to use PowerShell. I don’t feel you write the same PowerShell expression in all situations.
When using PowerShell interactively at a console prompt, the emphasis should be on speed and efficiency. As the name implies, PowerShell is as much a “shell” as anything else. You are typing commands to achieve a specific result. In these situations, I’m always telling my students to get in the habit of using tab-completion and PSReadline to write out the desired PowerShell expression quickly.
The console prompt is also the location where the use of PowerShell aliases is proper and effective. It is simple to build PowerShell muscle memory to write an expression like this quickly:
gsv | ? status -eq running | ogv -t 'Running'
You know what you wrote and could quickly type out the command. I use shortcuts and aliases constantly in PowerShell when running commands interactively. Commands you type at a PowerShell prompt are ephemeral.
Where this becomes a potential issue is with PowerShell scripting. The PowerShell script commands are no different from what you can run interactively. PowerShell won’t complain if you put the line above in a script file. However, I believe you need to take a different perspective. When you put code in a PowerShell script file, you are making a commitment. You are creating a permanent artifact that can be reused indefinitely.
The goal isn’t how quickly you can write the PowerShell expression. A good scripting editor like VSCode can assist with that. Instead, the goal should be clarity. PowerShell can be wordy, but it is meaningful. There is a reason cmdlet names follow a Verb-Noun naming convention, and parameters are generally consistent. These features make it easier to look at a line of PowerShell code and understand what it will do.
I always tell people, “Write your PowerShell scripts for the next person. It might be you!” In other words, you may write a “quick and dirty” PowerShell script only to have to edit it nine months later, and you need to take some time to recall how the code works. I have had more than one IT pro admit to this very problem. This confusion is why there is a community recommendation to avoid PowerShell aliases in your script files. Instead, take the time to write an expression like this:
Get-Service | Where-Object {$_.Status -eq 'running'} | Select-Object -property Name,Status,StartType,Displayname | Out-GridView -title "Running"I recommend using full cmdlet names and parameter names. However, I’m cheating a bit here with Where-Object. There is no confusion or misunderstanding about what this expression will do. Even if you knew very little PowerShell, you could make a solid, educated guess about the result.
There are a few other reasons for the full-name recommendation. First, because PowerShell is cross-platform, your code may be executed on non-Windows machines. On Linux, for example, you might not get the expected result if you run a PowerShell script that uses the alias Sort for Sort-Object because there is no sort alias. Instead, PowerShell will run the native sort command.
Who Are You Scripting For?
Ultimately, this comes down to a simple question, “Who is your PowerShell for?” If you are using PowerShell in an interactive console session, you can follow one set of guidelines. If you are writing a PowerShell module, there are a different set of community-accepted standards. That is one of the reasons we have tools like the PowerShell Script Analyzer.
I will take this a step further with PowerShell functions and tools. When you write a PowerShell function, you need to consider who will use it and what are their expectations? Maybe you are writing the command for yourself. Or perhaps it is for the intern on your team. Will the person executing your command need to enter many parameters? Parameters are a great way for writing flexible and re-usable code. Can your command be simplified by setting default values? Do you need a parameter alias that is more meaningful to the user?
Will the user typically pipe the output of a PowerShell command to your command, such as importing data from a CSV file? Will they pipe output from your command so another PowerShell command? In other words, how do you think your command will typically be used in the PowerShell ecosystem?
Summary
Understanding where PowerShell will be used and how is just as crucial as syntax and language, but are elements I think many IT Pros overlook. I firmly believe if you take the time to consider these points, you'll write better PowerShell code.