One feature of which I was reminded recently by my non-blogging friend John is PowerShell's support for exotic variable names. Let's try this out by example:

PowerShell code -

Yes, that was a single-quote mark, and yes, I did just name a variable using three exclamation points. That just happened!

I'm not telling you to go out there and start naming your variables with exclamation points because you're feeling chipper that day, even though, by the way, that's an excellent way to express yourself. I'm not telling you to do that.

What I am trying to say is that this "exotic variable name" feature is useful dealing with PowerShell's support for things like CSV import. Importing data using PowerShell's Import-CSV cmdlet automatically assigns the first "header row" as its property names. Sure, you're saying: who cares. Right. We name our header "CustomersFirstName", it comes out the other end $line.CustomersFirstName. YAWN!

 

While the collective "we" name our table headers in such a way that they won't break anything, just because we've been burned so many times, this defensive way of thinking does not always extend to whoever is supplying you with your CSV files. Or, let's just admit it, they're actually exports from someone's Excel spreadsheet. We'll definitely talk about working with Excel some other time; for now, it's back to the variable naming magic. Whereas before you'd say

foreach ($line in $importedCsvFile) {

    Write-Host $line.CustomersFirstName
}

now you can do::

foreach ($line in $importedCsvFile) {

    Write-Host $line.{Customer's First Name} #magic!
}

It's a subtle difference, but when you don't have control over the other guy's data, this sort of subtle issue can be a dealbreaker. Or, thinking positively, a deal-maker! Or, thinking positively but subversively, positively, definitely a dealbreaker! Or thinking non-positively, dealmaker buzzkill! There we go; I'm glad we all made it to the tail end of this paragraph. It's been a rough ride, but we persevered. Congratulations everyone on pushing through! You're all champions to me.

Metaprogramming

I'll mention in passing that, in addition to the ${exotic variable name} and $someVariable.{some exotic property name!!} syntax, we're also granted direct access to the object's methods, properties and other metadata via the $someVariable.PSObject property, which is bolted to every object. Check it out if you're interested; I've found real uses for it a few times. Moving along.

String syntax

We're also granted an odd syntax that allows strings to be used to look up a property. For example:

$worthlessExample = "This is a worthless example, sorry."

$worthessExample."Length"

As you might imagine, $worthlessExample."Length" gets the Length property of the string. That's all well and good, but let's spice it up, shall we?

$dynamicProperty = "Length"

$worthlessExample."$dynamicProperty"

Boom! There's some inline evaluation magic.

The PowerShell book

I would be remiss if I failed to mention that I learned all this from a single source: Bruce Payette's PowerShell book. This book has literally everything you need to know about working with PowerShell, which is quite a statement, especially when you compare it to my library of SharePoint books. So many SharePoint books, and yet so many holes in my SharePoint knowledge! I'm not complaining about SharePoint books so much as I'm trying to express how rare this situation is: you can master this technology with one book!