The next Out cmdlet I'd like to show you is Out‑String.
Let's take a look.
Okay, first off, we'll explore the help for Out‑String,
and this cmdlet will output the object as a string.
There's only a couple of parameters available with Out‑String,
as you can see in the syntax block.
And as noted in the description, Out‑String converts objects into strings,
and, by default,
it accumulates the strings and returns them as one single string.
There's a parameter called Stream, which you can use,
which will tell Out‑String to just process each object at a time.
So that ends up returning an array of strings rather than one single string.
I want to pause here just briefly and give you a reminder that
PowerShell is primarily an object‑based system.
So while you will end up needing to work with strings in one form or
another at some point in your PowerShell journey,
I definitely don't recommend converting objects to
strings unless you really need to.
It might feel normal for those that are coming from a Linux background to
want to work with strings and raw text in the output.
But you'll make life much easier if you can do your job working with
PowerShell objects rather than text and strings.
Let's run this thing to see what happens.
So we'll grab Get‑Process and pipe that across to Out‑String.
Interestingly,
this output looks pretty similar to what we've just seen
when running Get‑Process by itself.
We've got a table structure on the screen with processes listed,
but what you don't notice here immediately is that this is a
single object that is just a string of text.
In some of the other clips in this course,
we've piped Get‑Process to Get‑Member,
which has shown us the properties of the process object that we can work with.
If I rerun the command to output this to a string,
we'll pipe that to Get‑Member,
and I'll tack on the more command here so it doesn't run off the screen.
Notice here at the top that the type of object that is
currently in the pipeline is System.String.
That object has absolutely nothing to do with processes and process objects
because we converted it to a string using Out‑String.
All of the items that we're seeing here as I page through are methods of
things that we can do with string objects in PowerShell.
It's important that you understand that after piping to Out‑String,
you can now no longer work with the original
PowerShell objects and their properties.
For example, I'll create a new variable named $process.
And in that, we'll store the results of Get‑Process.
These are the raw PowerShell objects of the process type.
Let's check out the count property to see how many
objects we've got in that variable, and we've currently got 80.
I can get the first process stored in that collection of 80 by running
$process and telling it I want the first object,
which we can reference by using an opening square bracket,
0, to say I want the first object, and a closing square bracket.
PowerShell returns the first object in the variable.
Sweet.
I can choose to get the second object in the variable by doing the same thing,
but specifying a 1.
I can also pipe the variable to the select object
cmdlet and ask for the first object, or I can even ask for the first five.
If I pipe this across to Get‑Member,
notice at the top that the type is System.Diagnostics.Process.
And as I page through here,
these are all of the underlying properties related to process objects.
The point I'm trying to drive home with this example is that
we're still working with objects in the console.
Let's do some similar experiments when working with a string.
So I'll use the same $process variable.
And in that, we'll do Get‑Process and pipe it across to Out‑String.
If we check the count of objects in the $process variable,
so last time when we were dealing with objects,
we had 80.
But now that I've converted it to a string,
there's only one object in the variable.
If I run $process, that single object of a string gets output to the screen.
Let's run $process and tell PowerShell that we want just the first object.
So when we did this before, we got the first process in the variable.
But now that we're dealing with a string,
I don't have access to the objects in the same way that I did before.
If I pipe it to Select‑Object and ask for the first object,
well, we've only got one, which is that full string.
So PowerShell returns the entire string to our console.
To finish up here, I'd like to show you the Stream parameter,
which causes each block of text separated by a line break
to be treated as a separate stream.
Instead of storing the entire result as a single string object,
it will store each object coming across the pipeline in
its own string inside of an array.
So same command as before, but let's pop on the Stream parameter.
This time if we check the count, we've got 89 objects in total.
If I get the first object, it's actually a blank line.
But if I get the second object,
this time I can see the names of the headings for the
table that Get‑Process produces.
And if we get the third object,
it's a line of the dashes that are normally
underneath the table heading properties.
And if we go for the fourth object,
we get back the string relating to the first service.
So when using the Stream parameter,
each object that came down the pipeline is stored as its own string.
And with that said, if I pipe that across to Get‑Member,
we're still working with a string object here, not the object that was the output of the original Get‑Process command.