Understanding objects is one of the fundamental concepts to “getting” PowerShell. Join us as we explore objects and how they make PowerShell better than any other shell out there today.
Be sure to read the previous articles in the series:
And stay tuned for the rest of the series all week.
Objects
Have you ever wondered what sets PowerShell apart from a traditional Linux shell like Bash, or even the legacy command prompt? The answer is really simple: traditional shells output text, which makes it difficult to do things like formatting and filtering. Of course, there are tools to help you get the job done (sed and grep come to mind), but at the end of the day, if you want to do any kind of heavy text parsing, you need to know regular expressions like the back of your hand.
PowerShell takes advantage of the underlying .Net framework and takes a different approach, using objects instead of text. Objects are just a representation of something. They are a collection of parts and actions to use them. Let's take a look at the parts of a bicycle and how we might use them.
Objects in .Net are much the same except for two small differences: the “Parts” are called properties and the “Instructions” are called methods. If we wanted to represent a Windows Service as an object, we might decide that it is appropriate to describe it using three properties: Service Name, State and Description. We also need to interact with the service, so we might give the object a Start, a Stop and a Pause method.
You can see an object's properties and methods by passing it to the Get-Member cmdlet. The objects that a PowerShell cmdlet outputs are largely underlying types from the .Net framework, but you can create your own objects if you need to use a language like C# or use the PSObject type.
The Pipeline
There are plenty of Linux shells with a pipeline, allowing you to send the text that one command outputs as input to the next command in the pipeline. PowerShell takes this to the next level by allowing you to take the objects that one cmdlet outputs and pass them as input to the next cmdlet in the pipeline. The trick is knowing what type of object a cmdlet returns, which is really easy when using the Get-Member cmdlet.
Get-Service | Get-Member
For reasons beyond the scope of this article, properties and methods are jointly called class members, which explains why you use the Get-Member cmdlet to get a list of all the methods and properties an object has. However, the Get-Member cmdlet also returns another important piece of information, the underlying object type. In the above screenshot, we can see that Get-Service returns objects of the type:
System.ServiceProcess.ServiceController
Since PowerShell deals with objects and not text, not all cmdlets can be linked together using the pipeline[1]. That means we need to find a cmdlet that’s looking to accept a System.ServiceProcess.ServiceController object from the pipeline.
Get-Command -ParameterType System.ServiceProcess.ServiceController
Notice that there is a cmdlet called Stop-Service; let's take a look at the help for it.
Get-Help –Name Stop-Service
It looks like the InputObject parameter takes an array of ServiceController objects as input. Usually, if you see a parameter called InputObject, it will accept input from the Pipeline, but just to be sure let's take a look at the full help for that parameter.
Get-Help -Name Stop-Service –Full
Our suspicions were correct. So at this point we know the following:
- Get-Service returns ServiceController objects
- Stop-Service has a parameter called InputObject that accepts one or more ServiceControllers as input.
- The InputObject parameter accepts pipeline input.
Using this information we could do the following:
Get-Service -Name 'Apple Mobile Device' | Stop-Service
That’s all for this time folks. Next time we look at how we can format, filter and compare objects in the Pipeline.
Homework
If you have any questions you can tweet me @taybgibb, or just leave a comment.