PowerShell 2.0 embraces and extends an old idea in command-line administration — the pipeline. Understanding what can be done with this powerful feature is a key to being effective in the new, bold world of command-line administration of Windows systems.
The pipeline is not a new idea. Douglas McIlroy is a mathematician and programmer who noticed, back in the 70s, that the output of one command in Unix often became the input for the next. He put forward the idea of a “pipe” to send the output of one program directly to the input of another, skipping the step of saving that output in a file of some sort. A few years later in 1973, Unix co-creator Ken Thompson added the feature to Unix.
Pipeline Limits = Tool Development
One key limitation of the Unix pipeline (and of the CMD.EXE pipeline that eventually followed in DOS and Windows) was that it was only passing text from one command to the other. In other words, it wasn’t much more sophisticated than writing all the output to a file and reading it back in to give it to the next application. What the receiving program received was a tsunami of text. This led to the development of tools like grep, awk, sed, and Perl as ways to manipulate that big block of text to produce meaningful output to feed to that next program. This has been a workable approach for Unix users for generations now. Microsoft has taken a totally different approach with PowerShell, however. PowerShell’s pipeline isn’t passing plain text, it’s passing Objects.
Objects and You
Objects, in programmer-speak, are a software representation of a real-world thing. Real objects have properties: my pen has a certain quantity of ink in it; my computer has a screen with a certain number of inches in diagonal size. Real objects also usually support tasks we can perform on them: my car has a GoFaster and TurnLeft method (hey, I could be a NASCAR driver!). Programming objects represent a real-world thing using a set of properties and a set of methods that replicate the information and tasks that are relevant to using that thing in the real world. Applying that to computer technology, consider the idea of a Windows service. It’s a piece of software that runs in the background and allows your computer to perform some sort of functionality. What kinds of information do you want to know about a service? Things like the name of the service, the name of the executable it’s running, whether it’s stopped or started… things like that. What kinds of tasks do I need to perform to administer services? Well, I’d need to stop and start services, mostly. I might need to change the start mode from Automatic to Manual.
PowerShell represents the idea of a Windows service using an object. When I call on the Get-Service cmdlet to give me a list of services, what I get is actually a list of objects that represent those services. How do I know what kind of objects? I can pipe those objects to Get-Member and it will tell me all about it, like so: (and don’t forget, you can click on these images to see them at full size!)
So a service is an instance of a System.ServiceProcess.ServiceController object. What’s that? Remember that PowerShell is built on top of the .Net Framework, a large base of code for Windows application developers. .Net provides a vast list of types of objects that can be used to assemble programs, and they all have lengthy names like that one. Long story short, “ServiceController” objects are .Net’s way (and therefore PowerShell’s way) of describing services.