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

Photo of book cover

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