Most of the time when using PowerShell, especially when getting started,
you run a command and then accept the output that
you're shown by default on the screen.
But by understanding the PowerShell formatting system,
you can use it to your advantage to get data in exactly the
format you want and need when you need it.
In PowerShell, we're familiar with running a command, let' say Get‑Process.
And when that executes,
we get some output on the screen in the PowerShell
console in a human‑readable format.
That's great and all,
but what is this magic happening in the middle here that takes our input,
in this instance Get‑Process,
and then displays it for us in a way we can understand?
Put simply, that's no magic at all.
That is PowerShell's format system at work.
Let's spend a few minutes breaking this down to
understand the format system in more detail.
There's a secret I need to let you in on.
When you run a PowerShell command,
let's assume Get‑Process again for this example,
the objects that are returned by the command are
passed down the PowerShell pipeline,
even if you aren't explicitly piping them to another command.
What you don't see and, until now, have probably been unaware of,
is that every time you run a command,
it is always piped down to a cmdlet named Out‑Default.
It's always there because PowerShell adds it at the
end of the pipeline automatically.
It's the job of Out‑Default to decide how to format the data
that has been piped to it and output the object stream of
what is currently in the pipeline.
There's a couple of rules that Out‑Default follows.
First off, it checks to see if the object coming down the pipeline is a string.
If it is, Out‑Default pipes it directly to another cmdlet named Out‑Host,
which calls the appropriate APIs provided by the host to display the data.
What I mean by the host is the application that you're using
to interact with the PowerShell system.
Often, this is the standard PowerShell console,
which is what I'll be using in my demos.
But it might also be tools like Visual Studio Code with the built‑in terminal,
or the older ISE from Microsoft was another example of a host.
Out‑Host is another cmdlet that you don't need to
explicitly call in your command.
It happens automatically.
Now if the object coming down the pipeline isn't just a string,
this is where things can get a little bit more involved.
Out‑Default inspects the object being piped to it to determine what to do.
First off, it will look at the object type,
and it will determine whether there's a registered view or a formatter for this
object type that contains specific formatting instructions.
We'll circle back to the registered views in a moment.
Just stick with me here.
If there is a registered view,
this will contain information on how to format the data,
such as whether the data output should default to being a table or a list
and which properties of the object should be displayed.
And if it's a table, how wide the columns should be, so on and so forth.
That then gets sent to Out‑Host to be displayed back to you.
If there's not a registered view for the object type,
then Out‑Default looks at the first object coming down the pipeline
to determine how many properties these object has,
and then it follows a relatively simple rule.
If the object has five or more properties,
it sends the entire object stream to a cmdlet named Format‑List,
which will form at the data as a list and output it to the host.
If it has four or fewer properties,
it will send the entire stream to a cmdlet named Format‑Table where the data is
formatted into a table on the assumption that there is enough screen real
estate for you to view all four or fewer properties.
This default behavior can be overridden by you by explicitly
piping to a format command if you choose to do so,
and that's something we'll explore in the next clip.
I promised I'd swing back around and talk about these registered views,
so let's spend a moment or two on them.
Microsoft ships PowerShell with a number of registered views.
You can create your own views for PowerShell to use and then load
them in with a cmdlet named Update‑Format‑Data,
but that's well outside of the scope of this course.
In Windows PowerShell,
the views were defined in XML files that were stored in the PSHome directory,
which is where PowerShell was installed.
You could find them by running a command such as
what's on screen with Get‑ChildItem,
and these contain formatting instructions for different object types.
Now with PowerShell 7,
the default views for objects are defined in the PowerShell source code.
They aren't external files.
The format.ps1xml files from PowerShell 5.1 and earlier
don't exist in PowerShell 6 and onwards.
But what we can do to see the formatting rules is leverage a cmdlet named
Get‑FormatData to get information from PowerShell as to how it is going
to format output based on the object type.
I've extracted a couple of key lines from the help
file to bring to your attention.
So Get‑FormatData gets the formatting data in the current session.
You can use this cmdlet to examine the formatting data,
and we'll see that in the next clip.
Then you can use Export‑FormatData to serialize the objects,
convert them to XML, and save them in format.ps1xml files.
I'll also show you how to export the data out to XML in the next clip.
Later in this module, we're going to explore three formatting commands in detail,
and I've mentioned two of them already in this clip.
The first is Format‑Table, which is pretty self‑explanatory.
It will format the selected data to a table.
The second is Format‑List, which is also self‑explanatory.
The data will get formatted into a list for us.
The third is Format‑Wide, which formats the data in a table‑like structure,
but it will only display one property for each object being formatted.
The format commands do share some commonalities between them,
which I want to briefly touch on here.
You can tell PowerShell to autosize the results. By default,
PowerShell does a pretty good job of determining how to display the
data based on your console configuration.
But there may be times where forcing it to autosize makes
it display just that little bit nicer.
You can group results when formatting by using a parameter
named GroupBy, which allows you to group the results from a
command based on a particular property.
If you do this, you should sort the data first,
but I'll show you that in the demos. All of the format
commands allow you to specify alternate views,
which is not really a common topic. But if someone has gone to the
effort of creating a view for the data type,
there can be some interesting use cases to explore there.
And finally, I thought it was worth mentioning that for the most part,
you can and probably will just pipe commands or data to format commands,
and they will figure it out for you.
But all of the format commands do have a parameter named InputObject,
which allows you to specify which objects to format.
So, for example, you might have the results from a command stored in a variable.
And then you can just specify the variable in the
InputObject parameter of a format command.
It's important to pause here and reflect that the
format commands just format the data.
They are not responsible for displaying it or doing anything else with it,
like sending it out to a file or to the host.
The Out cmdlets are always used to do something with formatted data,
and we'll be exploring Out cmdlets in more detail later in this
course. Phew, there was a fair bit to digest there. So let's jump
into the PowerShell console and take a look at some of these concepts that we've just discussed.