The first format command I'd like to show you is Format‑Table.
Let's get stuck in.
Let's check out the help by running help Format‑Table.
So the synopsis here is pretty straightforward.
It formats the output as a table. Sweet! There are a number
of parameters available for Format‑Table,
and we'll take a look at a bunch of them shortly.
And there's, of course,
a detailed description here if you'd like to read through that in your own time.
Now there is an alias for Format‑Table.
So if I run, Get‑Alias ‑Definition Format‑Table,
we'll see the alias for this property is simply ft.
You'll probably see that used a lot on the internet,
and I personally use it a lot when I'm working at the console,
as well, because it's just quicker to type.
And no doubt you'll start to do the same.
Let me run a command that I know doesn't output to a table by default,
which is simply get‑date.
This output here is actually quite customized by the PowerShell format system,
but you can take a command, get‑date in this example,
and then pipe it down to Format‑Table to force the
output to be displayed in a table format.
And it's very likely that the formatting files are telling PowerShell
which properties to display here in this table.
Similarly, I know the command Get‑Host will default to a list.
Again, we can force this to a table simply by piping it to Format‑Table.
You might notice there that the value of that last property
is actually being truncated a little bit,
and we get shown the three dots to let us know there is more data.
Towards the end of this clip, I'll show you a way to stop that from happening.
Okay, let's grab a command that does output to a table by default.
So let's use Get‑Process.
If I scroll up, you can see this is indeed a table,
and there are headers at the top telling us what each column is.
If I pipe Get‑Process to Format‑Table, well,
I get exactly the same thing because the format system
was already doing that by default.
You can modify the properties being shown in the table in a few different ways.
You could pipe Get‑Process to a select object,
select the properties, and then pipe that down to Format‑Table.
Alternatively,
you could use the ‑Property parameter on Format‑Table to specify
which properties you want to be displayed.
Let's grab the Name, Responding, and Description properties.
And there we go.
I've still got the table,
but this time I've got the specific properties that I asked for.
I want to refer back to the help system for a moment to
bring up help for the GroupBy parameter.
I'll run Get‑Help Format‑Table and then specify the parameter GroupBy.
If I scroll up here a little,
there are a couple of things that I want to point out.
Using this parameter will group the output in separate
tables based on a property value.
But, importantly,
it says here that the GroupBy parameter expects the objects are sorted already,
so use the Sort‑Object cmdlet before using Format‑Table to group the objects.
Sweet!
No worries at all.
Let's give it a go.
If we run Get‑Process,
first we need to pipe that to Sort‑Object like the help told us to.
And I want to sort the results based on the ProcessName property.
Now that we've followed the rules and sorted,
we can pipe that down to Format‑Table and use the GroupBy parameter
to group the results based on the ProcessName.
And check this out, the results are now in individual little tables,
but they're all grouped according to their ProcessName.
You can see here there's only one process for winlogon,
so there's just one result there.
But there are two processes for WmiPrvSE,
and they're grouped together at the bottom.
If I scroll back quickly, you'll see everything is grouped out pretty nicely.
Another thing we can do while using GroupBy is also change the
properties being displayed in the output.
So, again, just like before,
if I put in the ‑Property parameter and then grab the Name,
Responding, and Description properties,
it will still group the results for me based on the ProcessName,
but it will only display the properties I've asked for.
There are a couple of other functions of Format‑Table that I'd like to show you.
Let's run Get‑WinEvent to grab Windows event log data from the
application log, and let's just limit the results here to 5 so we
don't get too much data in the console.
Okay, so by default, we get results formatted as a table, which is cool.
But there are a few things here.
Firstly,
there's a bit of dead space here between the TimeCreated and the ID properties.
Secondly,
the message is being cut off in all of the results because
it's too long to show on the screen.
Let's run that again but, this time, pipe it to Format‑Table. Now doing
just that would result in exactly the same thing.
So let's pop on the ‑AutoSize parameter. This time, if you look closely,
PowerShell's done a better job of trying to make the most of the PowerShell
console real estate to display as much information as it can.
You can see the gap between TimeCreated and ID has been closed,
which has allowed us to see a little bit more of the message,
but it's still getting cut off.
Another capability we have is to use the ‑Wrap parameter of Format‑Table,
which will tell PowerShell to wrap the values of the properties being
displayed to us so we can see the entire value on screen.
A couple of other quick things to take a look at before we move on.
Let me run, Get‑Process again and pipe it to Format‑Table,
and there's a parameter named ‑RepeatHeader.
If I scroll back a little bit,
you'll see the table header is repeated every so often,
and you might be wondering, Matt,
why? This can be handy if you do something like pipe it to the more command.
So those table headers will be repeated at every page scroll for
your PowerShell console. So you don't need to keep scrolling up and
down to see what the values represent.
Finally, there's also a parameter named ‑HideTableHeaders,
which,
as you can probably guess from the name, is going to show the
table but without the headers displayed. We'll only get the columns and the values of the properties.