Script Tips
The Scripting Pipeline
Save the script writing for when it's needed -- PowerShell allows stringing together of cmdlets to perform useful work.
If you remember a few months ago, I covered scripting with Powershell (see "
Shrinking Scripts
," May 2006). A nifty feature of PowerShell is the capability to use cmdlets, stringing them together -- look, ma, no script writing needed -- to perform useful work. The key is PowerShell’s pipelines, which aren’t at all unlike the piping you could do under the Cmd shell. It basically works like this:
Command1 | command2 | command3
Command1 runs, and its output is "piped" to Command2, which uses that input to do whatever it’s going to do and sends its output to Command3… ... and so forth. The trick with PowerShell is that cmdlets don’t output text, but rather entire objects (some of which might just be string objects containing text, of course). For example, if you run the Get-Process cmdlet, you’ll get a nice text listing of processes, but that’s just because PowerShell is doing some translating for you. What you’re really getting is a collection of Process objects -- PowerShell just knows you want something human-readable, and so it takes the most popular properties of the objects and formats a nice table for you.
You could pipe those objects directly to another cmdlet, though. Don’t try this at home (it’ll blue screen your computer), but here’s a simple example:
Get-Process | Stop-Process
That will take the list of all running processes and pipe them to the Stop-Process cmdlet which will, um, stop them. Hence the blue screen I mentioned earlier. But this is also a good time to point out how you can figure all this out on your own. The first step is to know what output any cmdlet is actually creating, regardless of any fancy formatting PowerShell might be doing:
Get-Process | Get-Member
Get-Member tells you what kind of object something is; in this case, it’s a System.Diagnostics.Process. Cool. If you run Help Stop-Process you’ll see three versions of its usage: One accepts an Int32 as its first parameter, which is named -Id, suggesting that it wants a process ID to stop. The second usage has the first parameter -Name, which is a string -- the name of the process you want to stop. The third usage has -InputObject as the first parameter, and it’s a System.Diagnostivcs.Process -- where did we see that before?
So when you run Stop-Process, it looks at the data type of the first parameter to figure out if you’re specifying a process ID, a process name or passing an actual process. When you pipe the output of Get-Process -- which, we’ve determined, is outputting a System.Diagnostics.Process object -- the Stop-Process cmdlet recognizes the data type and runs with the third usage example.
PowerShell RC1 is available for download from
http://www.microsoft.com/powershell
.
About the Author
With more than fifteen years of IT experience, Don Jones is one of the world’s leading experts on the Microsoft business technology platform. He’s the author of more than 35 books, including Windows PowerShell: TFM, Windows Administrator’s Scripting Toolkit, VBScript WMI and ADSI Unleashed, PHP-Nuke Garage, Special Edition Using Commerce Server 2002, Definitive Guide to SQL Server Performance Optimization, and many more. Don is a top-rated and in-demand speaker and serves on the advisory board for TechMentor. He is an accomplished IT journalist with features and monthly columns in Microsoft TechNet Magazine, Redmond Magazine, and on Web sites such as TechTarget and MCPMag.com. Don is also a multiple-year recipient of Microsoft’s prestigious Most Valuable Professional (MVP) Award, and is the Editor-in-Chief for Realtime Publishers.