Understand Embedded Objects in PowerShell

Summary: Microsoft Scripting Guy, Ed Wilson, talks about understanding embedded objects in Windows PowerShell.

 Hey, Scripting Guy! I don’t get it. Some things in Windows PowerShell are so easy, and others are so complicated. It seems to go from ridiculously easy to ridiculously hard all at once. Take for instance, the Get-Process cmdlet. I mean, a moron can use that cmdlet. It is not too hard to type Get-Process—in fact, the hardest part is remembering to use a hypen in the middle. But after I do that, now what?

There are things that just do not make sense, and things that are impossible to find. Why can’t Windows PowerShell simply return the information without all fuss and muss? I know I can pipe stuff to Format-List, and I even figured out that I can use a wildcard character like an asterisk ( * ) to get all of the properties, but that is where it falls off the rails. Some stuff is not there, and some things say only System.Diagnostics.ProcessStartInfo…whatever the heck that is. Can you help?

—ST

 Hello ST,

Microsoft Scripting Guy, Ed Wilson, is here. This is a somewhat sad time. I used the last of my Darjeeling Earl Grey tea that I bought in Hamburg, Germany. Maybe it is time to go back to Germany so I can get some more tea. Anyway, that is what I am drinking this morning—the last pot of my Darjeeling Earl Grey tea. I also have a whole grain English muffin with some French butter and homemade grape jam to go with it. It makes for a nice morning respite.

It is cool outside this morning, and somewhat rainy, but the tea and the muffin makes it seem warm somehow. I have my Surface Pro 3 outside with me, and I am checking the email in my scripter@microsoft.com account. ST, "I can feel your pain," as someone once said. But, luckily this is relatively easy to fix.

Everything is an object

Here are the top three things to remember about Windows PowerShell:

1. Everything is an object.
2. EVERYTHING is an object.
3. EVERTHING IS AN OBJECT.

This means that everything is, well, an object. For developer types, this makes intuitive sense, for IT pros, it can be somewhat confusing. Objects have methods—that is, they do things. They have properties—that is, they describe things. And they have events—that is, stuff that happens.

For example, let us consider an object such as a pickup truck. It has methods: the drive down the road method, the stop at a traffic signal method. It has properties: the color, number of doors, length, width, and number of tires properties. It also has events: the it hit a tree event.

But just as the pickup truck is an object, it is also made up of other objects. For example, the truck tires may also be objects. These truck tires also have color, size, inflation pressure, model number, and so on. So, if I were to use the Get-Pickup cmdlet, it might return the following:

So in the Tires property, I have an instance of the Vehicle.Tire object. To view the information contained in the Tires property, I need to expand that property.

Easy way to expand properties

As you may have already noticed, sending the results of a cmdlet to the Format-List cmdlet, even when using a wildcard character to show all of the properties, does not expand an embedded object. This is shown here:

I can see in this image that the StartInfo property contains an instance of the System.Diagnostics.ProcessStartInfo object. I do not necessarily need to remember that object name, but I do need to remember the property name: StartInfo.

I can then use that with the Select-Object cmdlet to view into the ProcessStartInfo object. Here is that command:

Get-Process | Select-Object -ExpandProperty startinfo

The command and associated output are shown here:

ST, that is all there is to using Windows PowerShell objects. Join me tomorrow when I will talk about more cool stuff.

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