More Things VBScripters Must Forget When Learning PowerShell

Following up onyesterday's post, I have one more thing that I'm still trying to purge out of my brain as I use PowerShell: Variables.

Now, don't get me wrong: There are puh-lenty of times when using a variable is absolutely the right thing. Mainly when you're writing a script that automates some complex process, or working with functions and whatnot (when variables hold your input arguments and parameters). However, there's lots of times when I've caught myself using variables when I didn't need to. Get a bunch of services using WMI, stick them in a variable. Enumerate through that variable and stick one service at a time into another variable. Grab information out of the service - like its name and status - and put those into variables. Format an output string and put that in yet another variable. Unlike natural resources, there's no shortage of variables, and so I use 'em a lot.

Actually, that pattern isn't at all unlike the way some Unix folks approach similar tasks: Get a bunch of services, write them to a file Grep the file for the services that are started, write the results to another file. Grep that file for the service names, write those to a file. Files, in a lot of Unix command-line patterns, are used as a kind of temporary storage mechanism - which is exactly what a variable is.

In PowerShell, you'll find plenty of places where using variables not only makes sense - it's practically mandatory. However, the pipeline itself is a kind of variable. That is, it's a temporary storage area for information that needs to travel between commands. So, rather than sticking information into a variable and then working with it, you can just stick it into the pipeline. The next command down the line receives whatever's in the pipeline - in much the same way as working with a variable.

Get-Service | Where { $_.Status -eq 'Running' } | Select Name,DisplayName | Format-Table -autoSize

Get-Process | Sort -property VM -descending | Select -first 10

Yeah, the syntax can seem a little goofy (what the heck is $_ supposed to remind me of?), but I always thought some of VBScript's syntax was a little goofy, too (ever see a WMI query?). I managed to learn that syntax - and memorize it well enough to do live demos at conferences - so I've been managing to learn PowerShell's goofy syntax, too. 

Again, this isn't a dig on VBScript. I used VBScript for close to 10 years and I'm still fond of it - heck, the last book I wrote for a mainstream publisher was on VBScript. But I like how, for many of the tasks I perform regularly, PowerShell's syntax is more concise and command-focused, and less like writing a program. Over the past three years, more and more of my tasks have become more straightforward in PowerShell than they were in VBScript, and I find myself able to do things I wasn't able to pull off in VBScript - mainly because Microsoft is actually making an effort with PowerShell, which they never really did with VBScript. Learning to use PowerShell in its own way has been tremendously rewarding.

Please or Register to post comments.

What's PowerShell with a Purpose Blog?

Don Jones demystifies Windows PowerShell.

Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×