Like This Blog 0

Added by Jason Helmick March 19, 2012

When writing an Advanced Function in PowerShell, many admins end their process block with the typical object creation lines to send an object down the pipeline. (I should say the ‘Good’ Admins do)

Focus on the last lines 33 and 34. In fact, let me zoom in a little for ya.

So, in typical PowerShell V2 fashion, I’m using New-Object to create a PSObject, then I’m splatting the properties to the object. Then next line is Write-Output to send that object down the pipeline. (p.s. you know to never use Write-Host, right?)

This is the typical way that myself and many other admins make the objects in PowerShell V2. In the below graphic is an example of a more consolidated way (almost a one-liner) to achieve the same results.

So, using a parenthetical on Write-Output, I can shorten my two lines into one. Cool, but to be honest I still prefer the two lines. It doesn’t take that long to type and it just seems more descriptive to me.

This is not the point of the article.

Version 3 of PowerShell promises to be a very refined version of PowerShell V2 with some enhancements. One of the enhancements comes in the way of an accelerator. Now if you’re an admin like me, you probably haven’t used the PowerShell accelerators much, we have cmdlets that perform the tasks, and an accelerator can usually be more confusing to a non-developer admin. That would be me. However notice the new syntax that is available in PowerShell V3 to create objects. Here’s a quick two liner.

Of course, you will quickly see there is an easy one-liner that we could make as well.

The accelerator is the [PSCustomObject] . Pretty cool huh? It really reduced the typing. Fun!

Hmmm. To be honest this is one of those times I appreciate the new feature, but almost wish it wasn’t a feature at all. The problem I see is that it does reduce the typing, as many of the accelerators are designed to do, but that’s kind of the issue.
In PowerShell, we tell folks when scripting to be very explanatory with their code. It makes reading and understanding the script later to be easier. It’s easier for others to troubleshoot and learn from. If you saw a blog or script and the author typed the following:

Gsv | ?{$_.status –eq “stopped}

The entire PowerShell community would behead that person. They used aliases, they didn’t use parameter descriptions……so on. I agree that at the console, in real-time, using the elastic notation of PowerShell is a true feature, but I agree that it is best to be fully explanatory in your scripts. So, the above line in a script should read;

Get-Service | Where-Object -FilterScript{$_.status –eq “stopped}

See? This is much easier to deal with in a script, and almost as fast to type thanks to Tab-Completion.

So that brings me back to the accelerator. If you’re an IT Admin, with little development experience, what should you do when you start writing a cmdlet with Advanced Functions?

I believe the answer has already been answered. New-Object –TypeName PSObject –Property …

It’s the most descriptive, the easiest to read and troubleshoot, and keeps with the established best practices.

HOWEVER! It is our responsibility to recognize the accelerator syntax, as you will certainly see many others, especially developer oriented folks, use the accelerator in their scripts. So when you see it in the future, you’ll know what it does.

Knowledge is PowerShell,
Jason Helmick
Director of PowerShell Technologies
Interface Technical Training