PowerShell Picasso

You have probably heard the story (or legend) about Pablo Picasso and his napkin drawing. A guy goes up to Picasso in a cafe and asks for an autograph or something. Picasso sketches out something in a minute or so. He turns to the guy and says, “That will be $10,000".”  The guy is stunned and replies “It only took you a minute!”. To which Picasso replies, “Yes, but it took a lifetime of experience.”

By now you’re wondering what this has to do with Windows PowerShell. Well, the reason Picasso could create a masterpiece in minutes on a napkin was because he already knew all the rules and knew how to apply them in the most efficient manner possible. Because he already knew “the long way” to do something, he was able to take a “shortcut”. I’m simplifying a bit to make my PowerShell analogy so stick with me.

There are several reasons I’m bringing this up, but primarily I want to see PowerShell adopted and spread throughout the enterprise. What I’m afraid of is that new-comers will see somebody’s napkin-based PowerShell script and think that’s pretty easy only to find out it is a lot more difficult.  You try copying a Picasso line drawing freehand.

Specifically, I’m referring to what I would like to see as a best practice regarding PowerShell writing and publishing. My first rule is to always use full cmdlet names and parameters in any PowerShell example. No aliases. Although there are a few exceptions which I’ll talk about in a moment. My reasoning for this rule is two-fold.  First, if you are writing a production script, there is no performance penalty for using full cmdlet names and parameters. In fact, there is a minor performance hit when using aliases because PowerShell has to resolve the alias. Cmdlet and parameter names are long, but at least they are meaningful. And when you come back to a script in a year, or when your successor with very little PowerShell experience has to update it, having plain-PowerShell language makes this much easier.

Even if you are posting a PowerShell example that will be run at the command line, I encourage you to use full names. Again, some brand new to PowerShell will likely be a little frustrated trying to figure out what this means:

ps | ? {$_.ws -gt 10mb} | %{ $_.path} | select -unique | sort -des

But if you use the full PowerShell syntax, it’s a little easier to swallow.

get-process | Where-Object {$_.WorkingSet -gt 10MB} | ForEach-Object {Write-Output $_.path} | Select-Object -Unique | Sort-Object -Descending

Once someone acquires some PowerShell experience, they can use the shortcuts in the console. I’m all for that. If you are running PowerShell as an interactive management shell, then by all means take advantage of every PowerShell shortcut to save on typing. But when sharing PowerShell knowledge, the same is counter-productive. With features like tab completion this should hardly be a tedious task.

As I mentioned, I have a few exceptions about the no alias rule that really boil down to common sense. Given a modicum of Windows experience, don’t use any alias that isn’t plain English or beyond basic experience.  Thus, I don’t have too much of a problem using DIR in an example. Yes, it is an alias for Get-ChildItem, but it is also such a common term that there’s no mystery. Compare that to aliases like gsv, clhy or nal. Yes, you can take the time to figure them out, but wouldn’t it be much easier to learn PowerShell with the full names of Get-Service, Clear-History, and New-Alias?

That said, if you need to use DIR with any number of parameters, then I would suggest using the full cmdlet name. A PowerShell example like this isn’t difficult to understand:

dir C:\temp

But as soon as you start increasing the complexity, the DIR command starts looking less like the DIR command an admin is familiar with it.

dir c:\temp -fi *.xml -for –rec

I’d rather see it expressed more completely.

get-childitem –path c:\temp –filter *.xml –force -recurse

My other concern regarding what I see in the community is the approach of PowerShell as a scripting language. Now don’t get me wrong. PowerShell as a scripting language and support for using  .NET objects directly is incredible stuff. But again, I come back to the young admin trying to see what PowerShell is all about and they come across a complex PowerShell example importing .NET assemblies, invoking methods directly and generally rising (in my opinion) to the level of systems programming. That’s not what admins need to see and I’d argue it is next to impossible to learn PowerShell from such examples. If you publish these types of examples, all I ask is that you explain that this is high-level stuff that can’t be accomplished using standard PowerShell cmdlets.

Which brings me to the end of today’s art of PowerShell lesson. Windows PowerShell is an rich, object-based interactive management shell. You combine one or more commands in a pipelined expression and do something useful. For more complex or repetitive tasks you can take the same commands you would type at the PS prompt and put them in a plain text script file.

While I respect the many PowerShell Picassos in the community, and we’re fortunate to have them, keep in mind that very few people can pick up Windows PowerShell and create masterpieces on the back of a napkin.  But they can take a clear and unambiguous example to learn from and over time discover what they can take away until they are left with pure PowerShell that is a work of art.

---

---