Why PowerShell Uses Objects
Summary: Microsoft PowerShell MVPs, Don Jones and Jeffery Hicks, show the flexibility and the power of Windows PowerShell objects.
Microsoft Scripting Guy, Ed Wilson, is here. This week we will not have our usual PowerTip. Instead we have excerpts from seven books from Manning Press. In addition, each blog will have a special code for 50% off the book being excerpted that day. Remember that the code is valid only for the day the excerpt is posted. The coupon code is also valid for a second book from the Manning collection.
Today, the excerpt is from Learn Windows PowerShell 3 in a Month of Lunches, Second Edition
By Don Jones and Jeffery Hicks
The use of objects in Windows PowerShell can be one of its most confusing elements, but at the same time it’s one of the critical concepts, affecting everything you do in “the shell.” We’ve tried different explanations over the years, and we’ve settled on a couple that work well for distinctly different audiences. This blog, based on Chapter 8 of Learn Windows PowerShell 3 in a Month of Lunches, shows you how Windows PowerShell uses objects.
One of the reasons why Windows PowerShell uses objects to represent data is, well, you have to represent data somehow, right? Windows PowerShell could have stored that data in a format like XML, or perhaps its creators could have decided to use plain-text tables. But they had some specific reasons why they didn’t take that route.
The first reason is that Windows itself is an object-oriented operating system—or at least, most of the software that runs on Windows is object oriented. Choosing to structure data as a set of objects is easy because most of the operating system lends itself to those structures.
Another reason to use objects is because they ultimately make things easier on you and give you more power and flexibility. For the moment, let’s pretend that Windows PowerShell doesn’t produce objects as the output of its commands. Instead, it produces simple text tables, which is what you probably thought it was doing in the first place. When you run a command like Get-Process, you’re getting formatted text as the output:
PS C:\> get-process
Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName
——- —— —– —– —– —— — ———–
39 5 1876 4340 52 11.33 1920 conhost
31 4 792 2260 22 0.00 2460 conhost
29 4 828 2284 41 0.25 3192 conhost
574 12 1864 3896 43 1.30 316 csrss
181 13 5892 6348 59 9.14 356 csrss
306 29 13936 18312 139 4.36 1300 dfsrs
125 15 2528 6048 37 0.17 1756 dfssvc
5159 7329 85052 86436 118 1.80 1356 dns
What if you wanted to do something else with this information? Perhaps you want to make a change to all of the processes running conhost. To do this, you’d have to filter the list a bit. In a UNIX or Linux shell, you’d use a command like Grep, telling it, “Look at this text list for me. Keep only those rows where columns 58–64 contain the characters ‘conhost.’ Delete all of the other rows.” The resulting list would contain only those processes you specified:
Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName
——- —— —– —– —– —— — ———–
39 5 1876 4340 52 11.33 1920 conhost
31 4 792 2260 22 0.00 2460 conhost
29 4 828 2284 41 0.25 3192 conhost
You’d then pipe that text to another command, perhaps telling it to extract the process ID from the list. “Go through this and get the characters from columns 52–56, but drop the first two (header) rows.” The result might be this:
1920
2460
3192
Finally, you’d pipe that text to yet another command, asking it to kill the processes (or whatever else you were trying to do) represented by those ID numbers.
This is, in fact, exactly how UNIX and Linux administrators work. They spend a lot of time learning how to get better at parsing text, using tools like Grep, Awk, and Sed, and becoming proficient in the use of regular expressions. Going through this learning process makes it easier for them to define the text patterns they want their computer to look for. UNIX and Linux folks like programming languages like Perl because those languages contain rich text-parsing and text-manipulation functions. But this text-based approach does present some problems:
- You can spend more time messing around with text than doing your real job.
- If the output of a command changes (say, moving the ProcessName column to the start of the table), you have to rewrite all of your commands because they’re all dependent on things like column positions.
- You have to become proficient in languages and tools that parse text—not because your job involves parsing text, but because parsing text is a means to an end.
The use of objects in Windows PowerShell helps remove all of that text manipulation overhead. Because objects work like tables in memory, you don’t have to tell Windows PowerShell in which text column a piece of information is located. Instead, you tell it the column name, and Windows PowerShell knows exactly where to go to get that data. Regardless of how you arrange the final output on the screen or in a file, the in-memory table is always the same, so you never have to rewrite your commands because a column moved. You spend a lot less time on overhead tasks, and more time focusing on what you want to accomplish.
Here is the code for the discount offer today at www.manning.com: scriptw4
Valid for 50% off Learn Windows PowerShell 3 in a Month of Lunches, Second Edition and Learn Windows IIS in a Month of Lunches
Offer valid from April 4, 2013 12:01 AM until April 5 midnight (EST)
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
Light
Dark
0 comments