PowerShell via .NET is full of different types of objects.
Now these are some of the most common ones you'll come across. A string
is just text. The int, the i‑n‑t that you see there, is an integer,
although you'll also see sometimes Int32 or Int64, which technically and
in .NET terms is something different.
But for our purposes, we're just going to treat them all as numbers.
DateTime should be self explanatory. And a Boolean is true or false.
In PowerShell, you'll use the Boolean variables $true and $false.
Now how can you discover what type of an object something is or what that
object looks like in terms of its properties and methods?
Well for that, we're going to use the Get‑Member cmdlet.
This cmdlet has an alias of gm,
which you'll use often, and you'll see it a lot in the wild.
Like help and Get‑Command, this is one of the most critical
cmdlets for you to learn and use often.
This is a key discovery command.
One of the reasons that this matters to you is that often
you'll need to discover the rest of the story. When you
run a command in PowerShell,
don't assume that the output that you see is all there is.
PowerShell often has a defined default view of different object types,
which almost never shows you, or almost never shows
you, all of the possible properties.
And in some cases,
PowerShell will use custom names to make the output more meaningful to you.
PowerShell tries to help you and abstract things from you.
Don't assume that what you see is all there is. And this will
become much clearer in the demonstration.
You need to be able to identify other properties because you'll be learning
and using cmdlets that will be able to use any property that you can
identify with Get‑Member. Think of Get‑Member as the authoritative source
for all information relating to an object.
And this can also help you. Not getting a result you expect when you run a
command? Rerun the command and pipe the results to Get‑Member to identify
what's coming out of the pipeline. Or, even better,
drop the last part of your pipeline expression and
pipe to Get‑Member. As you'll see, objects can change in the pipeline,
and you may not be ending up with what you started with.
So by now, it should be pretty clear to you that when you run a
PowerShell command it sends objects down the pipeline.
Although this isn't a locked‑in requirement,
you'll find plenty of code samples in the wild. And in the wild,
I mean that people have published on blogs and in code libraries
and GitHub and that sort of thing.
You'll find plenty of samples where people are using Write‑Host.
And they're using Write‑Host to omit the output,
which, as we saw in the last module,
sends output to the hosting application and not the pipeline.
These types of commands should be considered the exception and not the rule.
You'll also come across commands that don't write an object to the
pipeline because, you know, it just doesn't make sense.
If you kill a process,
the Stop‑Process command, by default, doesn't write anything to
the pipeline. And there's really no reason to. The process is gone
so what are you going to do with it?
Still, if you look at the Stop‑Process help, you'll see a ‑PassThru parameter.
Now if you use this parameter, the cmdlet, in this case Stop‑Process, will
write the object to the pipeline that it was working with.
This might be useful if you are using Stop‑Process in a
situation where you want to run the command and then send it
to something to create an audit trail.
Whenever you see ‑PassThru in the help for a command, that is
your clue that the command does not write anything to the
pipeline so you can't pipe anything from that command to
something else unless you use ‑PassThru.
Now of course what makes PowerShell easy is that you can join commands together.
Some commands are designed to accept or consume objects.
These commands may be designed to take an entire object,
or they may use properties of an incoming object.
Very often when you see a Get‑Command there'll be one or more
corresponding commands to do something with it.
So, Get‑Service has related commands to let you set,
stop, start, and restart a service.
You can get a bunch of services that meet some criteria and
then pipe them to something like Restart‑Service. Again,
there's no cryptic scripting.
It's a relatively simple PowerShell expression.
I always try to get people to think about this idea of managing at scale.
And this may make more sense when you get to scripting.
If you can do something for one object,
you can probably do the same thing to 100 or 1000 objects.
Don't think about doing something or writing a command to do one thing.
Think about how would I write it to do something for all things or 100 things. The PowerShell pipeline is what makes this possible.