A PowerShell Object Lesson: Part 2

Summary: Microsoft Scripting Guy, Ed Wilson, talks about the importance of returning objects to ease administrative work.

Microsoft Scripting Guy, Ed Wilson, is here. This afternoon I am sipping a magnificent cup of Oolong green tea. I added a spoonful of jasmine buds to my teapot, in addition to a half cinnamon stick and a spoonful of lemon grass. The result is perfect. It goes well with the macadamia nuts I am munching on right now.

Note  This is the second part of a three part series that talk about Windows PowerShell objects. In A PowerShell Object Lesson: Part 1, I talked about the advantage of using Windows PowerShell objects, and how they are helpful to the scripter.

I got it through the pipeline

The next really cool thing about objects is that I can send them down the pipeline to other commands. The other commands might do things or format things. For example, a common way that people who come from other scripting languages write scripts is to “echo” everything. When they find the Write-Host cmdlet, they immediately begin to select the properties they want to display. An example of such a script is shown in the following image:

Image of script

In addition to wasting a lot of time selecting properties, it takes a long time to write all that code. I am actually stepping back in time in terms of usefulness and productivity. The default output from Get-Process is actually better, in my opinion—and as will be seen in a bit, it is more useful. Here is the default output from Get-Process:

Image of command output

If I send the output to the Get-Member cmdlet, I can see that there are more properties available than just the default displayed here. In fact, there are a number of methods as shown in the following image:

Image of command output

The cool thing about methods is that methods do things. After I use the Get-Member cmdlet, the first thing that appears at the top of the screen is the TypeName line. It tells me that I have an instance of the System.Diagnostics.Process object. If I do not know what that is, I can look up that exact phrase on MSDN, and it will tell me everything about the object—including how to use the various methods that appear in the output.

The cool thing about Windows PowerShell and objects is that I do not need to dive into the .NET Framework or MSDN to be able to do some things. For example, my Process object has the following cmdlets that automatically work:

PS C:\> Get-Command -Noun process

 

CommandType     Name                                               ModuleName

———–     —-                                               ———-

Cmdlet          Debug-Process                                  Microsoft.Powe…

Cmdlet          Get-Process                                       Microsoft.Powe…

Cmdlet          Start-Process                                     Microsoft.Powe…

Cmdlet          Stop-Process                                     Microsoft.Powe…

Cmdlet          Wait-Process                                      Microsoft.Powe…

For example, if I want to stop the Notepad process, I can open MSDN and figure out how to call the Kill() method, or I can simply try the Stop-Process cmdlet. When I take the process object that comes from Get-Process and send it to the Stop-Process object, it automatically stops the processes. The command is shown here:

Get-Process notepad | Stop-Process

The following image illustrates the command, and then shows that Get-Process can no longer find any Notepad processes:

Image of message

Without using the pipeline, I would need to call the Kill method. It is not difficult, but it is another step. Here is an example:

PS C:\> $process = Get-Process notepad

PS C:\> $process.Kill()

Join me tomorrow when I will talk more about working with objects.

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