{"id":3885,"date":"2013-04-04T00:01:00","date_gmt":"2013-04-04T00:01:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/2013\/04\/04\/why-powershell-uses-objects\/"},"modified":"2013-04-04T00:01:00","modified_gmt":"2013-04-04T00:01:00","slug":"why-powershell-uses-objects","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/why-powershell-uses-objects\/","title":{"rendered":"Why PowerShell Uses Objects"},"content":{"rendered":"

Summary<\/strong>: Microsoft PowerShell MVPs, Don Jones and Jeffery Hicks, show the flexibility and the power of Windows PowerShell objects.<\/span><\/p>\n

Microsoft Scripting Guy, Ed Wilson, is here. This week we will not have our usual PowerTip<\/strong>. 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.<\/p>\n

Today, the excerpt is from Learn Windows PowerShell 3 in a Month of Lunches, Second Edition
<\/a>  By Don Jones and Jeffery Hicks<\/span><\/p>\n

\"Photo<\/a><\/p>\n

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<\/a>, shows you how Windows PowerShell uses objects.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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<\/strong>, you’re getting formatted text as the output: <\/span><\/p>\n

PS C:\\> get-process<\/p>\n

 <\/p>\n

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName<\/p>\n

——-  ——    —–      —– —–   ——     — ———–<\/p>\n

     39       5     1876       4340    52    11.33   1920 conhost<\/p>\n

     31       4      792       2260    22     0.00   2460 conhost<\/p>\n

     29       4      828       2284    41     0.25   3192 conhost<\/p>\n

    574      12     1864       3896    43     1.30    316 csrss<\/p>\n

    181      13     5892       6348    59     9.14    356 csrss<\/p>\n

    306      29    13936      18312   139     4.36   1300 dfsrs<\/p>\n

    125      15     2528       6048    37     0.17   1756 dfssvc<\/p>\n

   5159    7329    85052      86436   118     1.80   1356 dns<\/p>\n

What if you wanted to do something else with this information? Perhaps you want to make a change to all of the processes running <\/span>conhost<\/strong>. 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:<\/span><\/p>\n

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName<\/span><\/p>\n

——-  ——    —–      —– —–   ——     — ———–<\/p>\n

     39       5     1876       4340    52    11.33   1920 conhost<\/p>\n

     31       4      792       2260    22     0.00   2460 conhost<\/p>\n

     29       4      828       2284    41     0.25   3192 conhost <\/span><\/p>\n

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:<\/p>\n

1920<\/p>\n

2460<\/p>\n

3192<\/p>\n

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.<\/span><\/p>\n

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:<\/p>\n