A PowerShell host is a program that provides access to the PowerShell engine in order to run PowerShell commands and scripts. The PowerShell.exe that we saw in the PSHOME directory earlier in this chapter is known as the console host. It is cosmetically similar to Command Prompt (cmd.exe) and only provides a command-line interface. Starting with Version 2.0 of PowerShell, a second host was provided.

The Integrated Scripting Environment (ISE) is a graphical environment providing multiple editors in a tabbed interface along with menus and the ability to use plugins. While not as fully featured as an Integrated Development Environment (IDE), the ISE is a tremendous productivity tool used to build PowerShell scripts and is a great improvement over using an editor, such as notepad for development.

The ISE executable is stored in PSHOME, and is named powershell_ise.exe. In Version 2.0 of the ISE, there were three sections, a tabbed editor, a console for input, and a section for output. Starting with Version 3.0, the input and output sections were combined into a single console that is more similar to the interface of the console host. The Version 4.0 ISE is shown as follows:

I will be using the Light Console, Light Editor theme for the ISE in most of the screenshots for Module 1, because the dark console does not work well on the printed page. To switch to this theme, open the Options item in the Tools Menu and select Manage Themes... in the options window:

Press the Manage Themes... button, select the Light Console, Light Editor option from the list and press OK. Press OK again to exit the options screen and your ISE should look something similar to the following:

Note that you can customize the appearance of the text in the editor and the console pane in other ways as well. Other than switching to the light console display, I will try to keep the settings to default.

In addition to the console host and the ISE, if you have a 64-bit operating system, you will also have 64-bit and 32-bit PowerShell installations that will include separate copies of both the hosts.

As mentioned before, the main installation directory, or PSHOME, is found at %WINDIR%\System32\WindowsPowerShell\v1.0\. The version of PowerShell in PSHOME matches that of the the operating system. In other words, on a 64-bit OS, the PowerShell in PSHOME is 64-bit. On a 32-bit system, PSHOME has a 32-bit PowerShell install. On a 64-bit system, a second 32-bit system is found in %WINDIR%\SysWOW64\WindowsPowerShell\v1.0.

Looking in the Program Files\Accessories\Windows PowerShell menu in the start menu of a 64-bit Windows 7 install, we see the following:

Here, the 32-bit hosts are labeled as (x86) and the 64-bit versions are undesignated. When you run the 32-bit hosts on a 64-bit system, you will also see the (x86) designation in the title bar:

When you run a PowerShell host, the session is not elevated. This means that even though you might be an administrator of the machine, the PowerShell session is not running with administrator privileges. This is a safety feature to help prevent users from inadvertently running a script that damages the system.

In order to run a PowerShell session as an administrator, you have a couple of options. First, you can right-click on the shortcut for the host and select Run as administrator from the context menu. When you do this, unless you have disabled the UAC alerts, you will see a User Account Control (UAC) prompt verifying whether you want to allow the application to run as an administrator.

Selecting Yes allows the program to run as an administrator, and the title bar reflects that this is the case:

The second way to run one of the hosts as an administrator is to right-click on the shortcut and choose Properties. On the shortcut tab of the properties window, press the Advanced button. In the Advanced Properties window that pops up, check the Run as administrator checkbox and press OK, and OK again to exit out of the properties window:

Using this technique will cause the shortcut to always launch as an administrator, although the UAC prompt will still appear.

A PowerShell host is a program that provides access to the PowerShell engine in order to run PowerShell commands and scripts. The PowerShell.exe that we saw in the PSHOME directory earlier in this chapter is known as the console host. It is cosmetically similar to Command Prompt (cmd.exe) and only provides a command-line interface. Starting with Version 2.0 of PowerShell, a second host was provided.

The Integrated Scripting Environment (ISE) is a graphical environment providing multiple editors in a tabbed interface along with menus and the ability to use plugins. While not as fully featured as an Integrated Development Environment (IDE), the ISE is a tremendous productivity tool used to build PowerShell scripts and is a great improvement over using an editor, such as notepad for development.

The ISE executable is stored in PSHOME, and is named powershell_ise.exe. In Version 2.0 of the ISE, there were three sections, a tabbed editor, a console for input, and a section for output. Starting with Version 3.0, the input and output sections were combined into a single console that is more similar to the interface of the console host. The Version 4.0 ISE is shown as follows:

I will be using the Light Console, Light Editor theme for the ISE in most of the screenshots for Module 1, because the dark console does not work well on the printed page. To switch to this theme, open the Options item in the Tools Menu and select Manage Themes... in the options window:

Press the Manage Themes... button, select the Light Console, Light Editor option from the list and press OK. Press OK again to exit the options screen and your ISE should look something similar to the following:

Note that you can customize the appearance of the text in the editor and the console pane in other ways as well. Other than switching to the light console display, I will try to keep the settings to default.

In addition to the console host and the ISE, if you have a 64-bit operating system, you will also have 64-bit and 32-bit PowerShell installations that will include separate copies of both the hosts.

As mentioned before, the main installation directory, or PSHOME, is found at %WINDIR%\System32\WindowsPowerShell\v1.0\. The version of PowerShell in PSHOME matches that of the the operating system. In other words, on a 64-bit OS, the PowerShell in PSHOME is 64-bit. On a 32-bit system, PSHOME has a 32-bit PowerShell install. On a 64-bit system, a second 32-bit system is found in %WINDIR%\SysWOW64\WindowsPowerShell\v1.0.

Looking in the Program Files\Accessories\Windows PowerShell menu in the start menu of a 64-bit Windows 7 install, we see the following:

Here, the 32-bit hosts are labeled as (x86) and the 64-bit versions are undesignated. When you run the 32-bit hosts on a 64-bit system, you will also see the (x86) designation in the title bar:

When you run a PowerShell host, the session is not elevated. This means that even though you might be an administrator of the machine, the PowerShell session is not running with administrator privileges. This is a safety feature to help prevent users from inadvertently running a script that damages the system.

In order to run a PowerShell session as an administrator, you have a couple of options. First, you can right-click on the shortcut for the host and select Run as administrator from the context menu. When you do this, unless you have disabled the UAC alerts, you will see a User Account Control (UAC) prompt verifying whether you want to allow the application to run as an administrator.

Selecting Yes allows the program to run as an administrator, and the title bar reflects that this is the case:

The second way to run one of the hosts as an administrator is to right-click on the shortcut and choose Properties. On the shortcut tab of the properties window, press the Advanced button. In the Advanced Properties window that pops up, check the Run as administrator checkbox and press OK, and OK again to exit out of the properties window:

Using this technique will cause the shortcut to always launch as an administrator, although the UAC prompt will still appear.

In addition to the console host and the ISE, if you have a 64-bit operating system, you will also have 64-bit and 32-bit PowerShell installations that will include separate copies of both the hosts.

As mentioned before, the main installation directory, or PSHOME, is found at %WINDIR%\System32\WindowsPowerShell\v1.0\. The version of PowerShell in PSHOME matches that of the the operating system. In other words, on a 64-bit OS, the PowerShell in PSHOME is 64-bit. On a 32-bit system, PSHOME has a 32-bit PowerShell install. On a 64-bit system, a second 32-bit system is found in %WINDIR%\SysWOW64\WindowsPowerShell\v1.0.

Looking in the Program Files\Accessories\Windows PowerShell menu in the start menu of a 64-bit Windows 7 install, we see the following:

Here, the 32-bit hosts are labeled as (x86) and the 64-bit versions are undesignated. When you run the 32-bit hosts on a 64-bit system, you will also see the (x86) designation in the title bar:

When you run a PowerShell host, the session is not elevated. This means that even though you might be an administrator of the machine, the PowerShell session is not running with administrator privileges. This is a safety feature to help prevent users from inadvertently running a script that damages the system.

In order to run a PowerShell session as an administrator, you have a couple of options. First, you can right-click on the shortcut for the host and select Run as administrator from the context menu. When you do this, unless you have disabled the UAC alerts, you will see a User Account Control (UAC) prompt verifying whether you want to allow the application to run as an administrator.

Selecting Yes allows the program to run as an administrator, and the title bar reflects that this is the case:

The second way to run one of the hosts as an administrator is to right-click on the shortcut and choose Properties. On the shortcut tab of the properties window, press the Advanced button. In the Advanced Properties window that pops up, check the Run as administrator checkbox and press OK, and OK again to exit out of the properties window:

Using this technique will cause the shortcut to always launch as an administrator, although the UAC prompt will still appear.

When you run a PowerShell host, the session is not elevated. This means that even though you might be an administrator of the machine, the PowerShell session is not running with administrator privileges. This is a safety feature to help prevent users from inadvertently running a script that damages the system.

In order to run a PowerShell session as an administrator, you have a couple of options. First, you can right-click on the shortcut for the host and select Run as administrator from the context menu. When you do this, unless you have disabled the UAC alerts, you will see a User Account Control (UAC) prompt verifying whether you want to allow the application to run as an administrator.

Selecting Yes allows the program to run as an administrator, and the title bar reflects that this is the case:

The second way to run one of the hosts as an administrator is to right-click on the shortcut and choose Properties. On the shortcut tab of the properties window, press the Advanced button. In the Advanced Properties window that pops up, check the Run as administrator checkbox and press OK, and OK again to exit out of the properties window:

Using this technique will cause the shortcut to always launch as an administrator, although the UAC prompt will still appear.

The output that we see in the preceding screenshot includes several details about a single file. Note that there is a lot of formatting included with the static text (for example, Volume in drive) and some tabular information, but the only way to get to these details is to understand exactly how the output is formatted and parse the output string accordingly. Think about how the output would change, if there were more than one file listed. If we included the /S switch, the output would have spanned over multiple directories, and would have been broken into sections accordingly. Finding a specific piece of information from this is not a trivial operation, and the process of retrieving the file length, for example, would be different from how you would go about retrieving the file extension.

Another command that we are all familiar with is the IPConfig.exe tool, which shows network adapter information. Here is the beginning of the output in my laptop:

Here, again, the output is very mixed. There is a lot of static text and a list of properties and values. The property names are very readable, which is nice for humans, but not so nice for computers trying to parse things out. The dot-leaders are again something that help to guide the eyes towards the property values, but will get in the way when we try to parse out the values that we are looking for. Since some of the values (such as IP addresses and subnet masks) already include dots, I imagine it will cause some confusion.

Let's look at some PowerShell commands and compare how easy it is to get what we need out of the output:

We can see that the output of the dir command looks similar to the output we saw in DOS, but we can follow this with Select-Object to pull out a specific property. This is possible because PowerShell commands always output objects. In this case, the object in question has a property called Extension, which we can inspect. We will talk about the select-object cmdlet in detail in the next chapter, but for now it is enough to know that it can be used to limit the output to a specific set of properties from the original objects.

The output that we see in the preceding screenshot includes several details about a single file. Note that there is a lot of formatting included with the static text (for example, Volume in drive) and some tabular information, but the only way to get to these details is to understand exactly how the output is formatted and parse the output string accordingly. Think about how the output would change, if there were more than one file listed. If we included the /S switch, the output would have spanned over multiple directories, and would have been broken into sections accordingly. Finding a specific piece of information from this is not a trivial operation, and the process of retrieving the file length, for example, would be different from how you would go about retrieving the file extension.

Another command that we are all familiar with is the IPConfig.exe tool, which shows network adapter information. Here is the beginning of the output in my laptop:

Here, again, the output is very mixed. There is a lot of static text and a list of properties and values. The property names are very readable, which is nice for humans, but not so nice for computers trying to parse things out. The dot-leaders are again something that help to guide the eyes towards the property values, but will get in the way when we try to parse out the values that we are looking for. Since some of the values (such as IP addresses and subnet masks) already include dots, I imagine it will cause some confusion.

Let's look at some PowerShell commands and compare how easy it is to get what we need out of the output:

We can see that the output of the dir command looks similar to the output we saw in DOS, but we can follow this with Select-Object to pull out a specific property. This is possible because PowerShell commands always output objects. In this case, the object in question has a property called Extension, which we can inspect. We will talk about the select-object cmdlet in detail in the next chapter, but for now it is enough to know that it can be used to limit the output to a specific set of properties from the original objects.

Another command that we are all familiar with is the IPConfig.exe tool, which shows network adapter information. Here is the beginning of the output in my laptop:

Here, again, the output is very mixed. There is a lot of static text and a list of properties and values. The property names are very readable, which is nice for humans, but not so nice for computers trying to parse things out. The dot-leaders are again something that help to guide the eyes towards the property values, but will get in the way when we try to parse out the values that we are looking for. Since some of the values (such as IP addresses and subnet masks) already include dots, I imagine it will cause some confusion.

Let's look at some PowerShell commands and compare how easy it is to get what we need out of the output:

We can see that the output of the dir command looks similar to the output we saw in DOS, but we can follow this with Select-Object to pull out a specific property. This is possible because PowerShell commands always output objects. In this case, the object in question has a property called Extension, which we can inspect. We will talk about the select-object cmdlet in detail in the next chapter, but for now it is enough to know that it can be used to limit the output to a specific set of properties from the original objects.

Let's look at some PowerShell commands and compare how easy it is to get what we need out of the output:

We can see that the output of the dir command looks similar to the output we saw in DOS, but we can follow this with Select-Object to pull out a specific property. This is possible because PowerShell commands always output objects. In this case, the object in question has a property called Extension, which we can inspect. We will talk about the select-object cmdlet in detail in the next chapter, but for now it is enough to know that it can be used to limit the output to a specific set of properties from the original objects.

Sorting data can be interesting. Have you ever sorted a list of numbers only to find that 11 came between 1 and 2? That's because the sort that you used treated the numbers as text. Sorting dates with all the different culture-specific formatting can also be a challenge. Fortunately, PowerShell handles sorting details for you with the Sort-Object cmdlet.

Let's look at a few examples of the Sort-Object cmdlet before getting into the details. We'll start by sorting a directory listing by length:

Sorting this in reverse isn't difficult either.

Sorting by more than one property is a breeze as well. Here, I omitted the parameter name (-Property) to shorten the command-line a bit:

Looking at the brief help for the Sort-Object cmdlet, we can see a few other parameters, such as:

As it turns out, you will probably find few occasions to use these parameters and will be fine with the –Property and –Descending parameters.

Another cmdlet that is extremely useful is the Where-Object cmdlet. Where-Object is used to filter the pipeline data based on a condition that is tested for each item in the pipeline. Any object in the pipeline that causes the condition to evaluate to a true value is output from the Where-Object cmdlet. Objects that cause the condition to evaluate to a false value are not passed on as output.

For instance, we might want to find all the files that are below 100 bytes in size in the c:\temp directory. One way to do that is to use the simplified, or comparison syntax for Where-Object, which was introduced in PowerShell 3.0. In this syntax, the command would look like this:

Dir c:\temp | Where-Object Length –lt 100

In this syntax, we can compare a single property of each object with a constant value. The comparison operator here is –lt, which is how PowerShell expresses "less than".

If you need to use PowerShell 1.0 or 2.0, or need to specify a condition more complex than it is allowed in the simplified syntax, you can use the general or scriptblock syntax. Expressing the same condition using this form looks as follows:

Dir c:\temp | Where-Object {$_.Length –lt 100}

This looks a lot more complicated, but it's not so bad. The construction in curly braces is called a scriptblock, and is simply a block of the PowerShell code. In the scriptblock syntax, $_ stands for the current object in the pipeline and we're referencing the Length property of that object using dot-notation. The good thing about the general syntax of Where-Object is that we can do more inside the scriptblock than simply test one condition. For instance, we could check for files below 100 bytes or those that were created after 1/1/2015, as follows:

Dir c:\temp | Where-Object {$_.Length –lt 100 –or $_.CreationTime –gt '1/1/2015'}

Here's this command running on my laptop:

If you're using PowerShell 3.0 or above and need to use the scriptblock syntax, you can substitute $_ with $PSItem in the scriptblock. The meaning is the same and $PSItem is a bit more readable. It makes the line slightly longer, but it's a small sacrifice to make for readability's sake.

The examples that I've shown so far, have used simple comparisons with properties, but in the scriptblock syntax, any condition can be included. Also, note that any value other than a logical false value (expressed by $false in PowerShell), 0, or an empty string ('') is considered to be true ($true) in PowerShell. So, for example, we could filter objects using the Get-Member cmdlet to only show objects that have a particular property, as follows:

Dir | where-object {$_ | get-member Length}

This will return all objects in the current directory that have a Length property. Since files have lengths and directories don't, this is one way to get a list of files and omit the subdirectories.

The Select-Object cmdlet is a versatile cmdlet that you will find yourself using often. There are three main ways that it is used:

Limiting the number of objects returned

Sometimes, you just want to see a few of the objects that are in the pipeline. To accomplish this, you can use the -First, -Last, and -Skip parameters. The -First parameter indicates that you want to see a particular number of objects from the beginning of the list of objects in the pipeline. Similarly, the -Last parameter selects objects from the end of the list of objects in the pipeline.

For instance, getting the first two processes in the list from Get-Process is simple:

Since we didn't use Sort-Object to force the order of the objects in the pipeline, we don't know that these are the first alphabetically, but they were the first two that were output from Get-Process.

You can use –Skip to cause a certain number of objects to be bypassed before returning the objects. It can be used by itself to output the rest of the objects after the skipped ones, or in conjunction with –First or –Last to return all but the beginning or end of the list of objects. As an example, -Skip can be used to skip over header lines when reading a file using the Get-Content cmdlet.

Limiting the properties of the objects returned

Sometimes, the objects in the pipeline have more properties than you need. To select only certain properties from the list of objects in the pipeline, you can use the –Property parameter with a list of properties. For instance, to get only the Name, Extension, and Length from the directory listing, you could do something like this:

I used the –First parameter as well to save some space in the output, but the important thing is that we only got the three properties that we asked for.

Note that, here, the first two objects in the pipeline were directories, and directory objects don't have a length property. PowerShell provides an empty value of $null for missing properties like this. Also, note that these objects weren't formatted like a directory listing. We'll talk about formatting in detail in the next chapter, but for now, you should just know that these limited objects are not of the same type as the original objects, so the formatting system treated them differently.

Tip

You try it!

Use the Get-Member cmdlet to verify that the type of the objects change slightly when you use the –Property parameter of Select-Object.

Retrieving the values of a single property

Sometimes, you want to get the values of a single property of a set of objects. For instance, if you wanted to get the display names of all of the services installed on your computer, you might try to do something like this:

This is close to what you were looking for, but instead of getting a bunch of names (strings), you got a bunch of objects with the DisplayName properties. A hint that this is what happened is seen by the heading (and underline) of DisplayName. You can also verify this using the Get-Member cmdlet:

In order to just get the values and not objects, you need to use the –ExpandProperty parameter. Unlike the –Property parameter, you can only specify a single property with –ExpandProperty, and the output is a list of raw values. Notice that with –ExpandProperty, the column heading is gone:

We can also verify using Get-Member that we just got strings instead of objects with a DisplayName property:

There are a few other parameters for Select-Object, but they will be less commonly used than the ones listed here.

The Measure-Object cmdlet has a simple function. It calculates statistics based on the objects in the pipeline. Its most basic form takes no parameters, and simply counts the objects that are in the pipeline.

To count the files in c:\temp and its subfolders, you could write:

Dir c:\temp –recurse –file | Measure-Object

The output shows the count, and also some other properties that give a hint about the other uses of the cmdlet. To populate these other fields, you will need to provide the name of the property that is used to calculate them and also specify which field(s) you want to calculate. The calculations are specified using the –Sum, -Minimum, -Maximum, and –Average switches.

For instance, to add up (sum) the lengths of the files in the C:\Windows directory, you could issue this command:

Dir c:\Windows | Measure-Object –Property Length –Sum

The Group-Object cmdlet divides the objects in the pipeline into distinct sets based on a property or a set of properties. For instance, we can categorize the files in a folder by their extensions using Group-Object like this:

You will notice in the output that PowerShell has provided the count of items in each set, the value of the property (Extension) that labels the set, and a property called Group, which contains all of the original objects that were on the pipeline that ended up in the set. If you have used the GROUP BY clause in SQL and are used to losing the original information when you group, you'll be pleased to know that PowerShell retains those objects in their original state in the Group property of the output.

If you don't need the objects and are simply concerned with what the counts are, you can use the –NoElement switch, which causes the Group property to be omitted.

You're not limited to grouping by a single property either. If you want to see files grouped by mode (read-only, archive, etc.) and extension, you can simply list both properties.

Note that the Name property of each set is now a list of two values corresponding to the two properties defining the group.

The Group-Object cmdlet can be useful to summarize the objects, but you will probably not use it nearly as much as Sort-Object, Where-Object, and Select-Object.

Sorting data can be interesting. Have you ever sorted a list of numbers only to find that 11 came between 1 and 2? That's because the sort that you used treated the numbers as text. Sorting dates with all the different culture-specific formatting can also be a challenge. Fortunately, PowerShell handles sorting details for you with the Sort-Object cmdlet.

Let's look at a few examples of the Sort-Object cmdlet before getting into the details. We'll start by sorting a directory listing by length:

Sorting this in reverse isn't difficult either.

Sorting by more than one property is a breeze as well. Here, I omitted the parameter name (-Property) to shorten the command-line a bit:

Looking at the brief help for the Sort-Object cmdlet, we can see a few other parameters, such as:

As it turns out, you will probably find few occasions to use these parameters and will be fine with the –Property and –Descending parameters.

Another cmdlet that is extremely useful is the Where-Object cmdlet. Where-Object is used to filter the pipeline data based on a condition that is tested for each item in the pipeline. Any object in the pipeline that causes the condition to evaluate to a true value is output from the Where-Object cmdlet. Objects that cause the condition to evaluate to a false value are not passed on as output.

For instance, we might want to find all the files that are below 100 bytes in size in the c:\temp directory. One way to do that is to use the simplified, or comparison syntax for Where-Object, which was introduced in PowerShell 3.0. In this syntax, the command would look like this:

Dir c:\temp | Where-Object Length –lt 100

In this syntax, we can compare a single property of each object with a constant value. The comparison operator here is –lt, which is how PowerShell expresses "less than".

If you need to use PowerShell 1.0 or 2.0, or need to specify a condition more complex than it is allowed in the simplified syntax, you can use the general or scriptblock syntax. Expressing the same condition using this form looks as follows:

Dir c:\temp | Where-Object {$_.Length –lt 100}

This looks a lot more complicated, but it's not so bad. The construction in curly braces is called a scriptblock, and is simply a block of the PowerShell code. In the scriptblock syntax, $_ stands for the current object in the pipeline and we're referencing the Length property of that object using dot-notation. The good thing about the general syntax of Where-Object is that we can do more inside the scriptblock than simply test one condition. For instance, we could check for files below 100 bytes or those that were created after 1/1/2015, as follows:

Dir c:\temp | Where-Object {$_.Length –lt 100 –or $_.CreationTime –gt '1/1/2015'}

Here's this command running on my laptop:

If you're using PowerShell 3.0 or above and need to use the scriptblock syntax, you can substitute $_ with $PSItem in the scriptblock. The meaning is the same and $PSItem is a bit more readable. It makes the line slightly longer, but it's a small sacrifice to make for readability's sake.

The examples that I've shown so far, have used simple comparisons with properties, but in the scriptblock syntax, any condition can be included. Also, note that any value other than a logical false value (expressed by $false in PowerShell), 0, or an empty string ('') is considered to be true ($true) in PowerShell. So, for example, we could filter objects using the Get-Member cmdlet to only show objects that have a particular property, as follows:

Dir | where-object {$_ | get-member Length}

This will return all objects in the current directory that have a Length property. Since files have lengths and directories don't, this is one way to get a list of files and omit the subdirectories.

The Select-Object cmdlet is a versatile cmdlet that you will find yourself using often. There are three main ways that it is used:

Limiting the number of objects returned

Sometimes, you just want to see a few of the objects that are in the pipeline. To accomplish this, you can use the -First, -Last, and -Skip parameters. The -First parameter indicates that you want to see a particular number of objects from the beginning of the list of objects in the pipeline. Similarly, the -Last parameter selects objects from the end of the list of objects in the pipeline.

For instance, getting the first two processes in the list from Get-Process is simple:

Since we didn't use Sort-Object to force the order of the objects in the pipeline, we don't know that these are the first alphabetically, but they were the first two that were output from Get-Process.

You can use –Skip to cause a certain number of objects to be bypassed before returning the objects. It can be used by itself to output the rest of the objects after the skipped ones, or in conjunction with –First or –Last to return all but the beginning or end of the list of objects. As an example, -Skip can be used to skip over header lines when reading a file using the Get-Content cmdlet.

Limiting the properties of the objects returned

Sometimes, the objects in the pipeline have more properties than you need. To select only certain properties from the list of objects in the pipeline, you can use the –Property parameter with a list of properties. For instance, to get only the Name, Extension, and Length from the directory listing, you could do something like this:

I used the –First parameter as well to save some space in the output, but the important thing is that we only got the three properties that we asked for.

Note that, here, the first two objects in the pipeline were directories, and directory objects don't have a length property. PowerShell provides an empty value of $null for missing properties like this. Also, note that these objects weren't formatted like a directory listing. We'll talk about formatting in detail in the next chapter, but for now, you should just know that these limited objects are not of the same type as the original objects, so the formatting system treated them differently.

Tip

You try it!

Use the Get-Member cmdlet to verify that the type of the objects change slightly when you use the –Property parameter of Select-Object.

Retrieving the values of a single property

Sometimes, you want to get the values of a single property of a set of objects. For instance, if you wanted to get the display names of all of the services installed on your computer, you might try to do something like this:

This is close to what you were looking for, but instead of getting a bunch of names (strings), you got a bunch of objects with the DisplayName properties. A hint that this is what happened is seen by the heading (and underline) of DisplayName. You can also verify this using the Get-Member cmdlet:

In order to just get the values and not objects, you need to use the –ExpandProperty parameter. Unlike the –Property parameter, you can only specify a single property with –ExpandProperty, and the output is a list of raw values. Notice that with –ExpandProperty, the column heading is gone:

We can also verify using Get-Member that we just got strings instead of objects with a DisplayName property:

There are a few other parameters for Select-Object, but they will be less commonly used than the ones listed here.

The Measure-Object cmdlet has a simple function. It calculates statistics based on the objects in the pipeline. Its most basic form takes no parameters, and simply counts the objects that are in the pipeline.

To count the files in c:\temp and its subfolders, you could write:

Dir c:\temp –recurse –file | Measure-Object

The output shows the count, and also some other properties that give a hint about the other uses of the cmdlet. To populate these other fields, you will need to provide the name of the property that is used to calculate them and also specify which field(s) you want to calculate. The calculations are specified using the –Sum, -Minimum, -Maximum, and –Average switches.

For instance, to add up (sum) the lengths of the files in the C:\Windows directory, you could issue this command:

Dir c:\Windows | Measure-Object –Property Length –Sum

The Group-Object cmdlet divides the objects in the pipeline into distinct sets based on a property or a set of properties. For instance, we can categorize the files in a folder by their extensions using Group-Object like this:

You will notice in the output that PowerShell has provided the count of items in each set, the value of the property (Extension) that labels the set, and a property called Group, which contains all of the original objects that were on the pipeline that ended up in the set. If you have used the GROUP BY clause in SQL and are used to losing the original information when you group, you'll be pleased to know that PowerShell retains those objects in their original state in the Group property of the output.

If you don't need the objects and are simply concerned with what the counts are, you can use the –NoElement switch, which causes the Group property to be omitted.

You're not limited to grouping by a single property either. If you want to see files grouped by mode (read-only, archive, etc.) and extension, you can simply list both properties.

Note that the Name property of each set is now a list of two values corresponding to the two properties defining the group.

The Group-Object cmdlet can be useful to summarize the objects, but you will probably not use it nearly as much as Sort-Object, Where-Object, and Select-Object.

Another cmdlet that is extremely useful is the Where-Object cmdlet. Where-Object is used to filter the pipeline data based on a condition that is tested for each item in the pipeline. Any object in the pipeline that causes the condition to evaluate to a true value is output from the Where-Object cmdlet. Objects that cause the condition to evaluate to a false value are not passed on as output.

For instance, we might want to find all the files that are below 100 bytes in size in the c:\temp directory. One way to do that is to use the simplified, or comparison syntax for Where-Object, which was introduced in PowerShell 3.0. In this syntax, the command would look like this:

Dir c:\temp | Where-Object Length –lt 100

In this syntax, we can compare a single property of each object with a constant value. The comparison operator here is –lt, which is how PowerShell expresses "less than".

If you need to use PowerShell 1.0 or 2.0, or need to specify a condition more complex than it is allowed in the simplified syntax, you can use the general or scriptblock syntax. Expressing the same condition using this form looks as follows:

Dir c:\temp | Where-Object {$_.Length –lt 100}

This looks a lot more complicated, but it's not so bad. The construction in curly braces is called a scriptblock, and is simply a block of the PowerShell code. In the scriptblock syntax, $_ stands for the current object in the pipeline and we're referencing the Length property of that object using dot-notation. The good thing about the general syntax of Where-Object is that we can do more inside the scriptblock than simply test one condition. For instance, we could check for files below 100 bytes or those that were created after 1/1/2015, as follows:

Dir c:\temp | Where-Object {$_.Length –lt 100 –or $_.CreationTime –gt '1/1/2015'}

Here's this command running on my laptop:

If you're using PowerShell 3.0 or above and need to use the scriptblock syntax, you can substitute $_ with $PSItem in the scriptblock. The meaning is the same and $PSItem is a bit more readable. It makes the line slightly longer, but it's a small sacrifice to make for readability's sake.

The examples that I've shown so far, have used simple comparisons with properties, but in the scriptblock syntax, any condition can be included. Also, note that any value other than a logical false value (expressed by $false in PowerShell), 0, or an empty string ('') is considered to be true ($true) in PowerShell. So, for example, we could filter objects using the Get-Member cmdlet to only show objects that have a particular property, as follows:

Dir | where-object {$_ | get-member Length}

This will return all objects in the current directory that have a Length property. Since files have lengths and directories don't, this is one way to get a list of files and omit the subdirectories.

The Select-Object cmdlet is a versatile cmdlet that you will find yourself using often. There are three main ways that it is used:

Limiting the number of objects returned

Sometimes, you just want to see a few of the objects that are in the pipeline. To accomplish this, you can use the -First, -Last, and -Skip parameters. The -First parameter indicates that you want to see a particular number of objects from the beginning of the list of objects in the pipeline. Similarly, the -Last parameter selects objects from the end of the list of objects in the pipeline.

For instance, getting the first two processes in the list from Get-Process is simple:

Since we didn't use Sort-Object to force the order of the objects in the pipeline, we don't know that these are the first alphabetically, but they were the first two that were output from Get-Process.

You can use –Skip to cause a certain number of objects to be bypassed before returning the objects. It can be used by itself to output the rest of the objects after the skipped ones, or in conjunction with –First or –Last to return all but the beginning or end of the list of objects. As an example, -Skip can be used to skip over header lines when reading a file using the Get-Content cmdlet.

Limiting the properties of the objects returned

Sometimes, the objects in the pipeline have more properties than you need. To select only certain properties from the list of objects in the pipeline, you can use the –Property parameter with a list of properties. For instance, to get only the Name, Extension, and Length from the directory listing, you could do something like this:

I used the –First parameter as well to save some space in the output, but the important thing is that we only got the three properties that we asked for.

Note that, here, the first two objects in the pipeline were directories, and directory objects don't have a length property. PowerShell provides an empty value of $null for missing properties like this. Also, note that these objects weren't formatted like a directory listing. We'll talk about formatting in detail in the next chapter, but for now, you should just know that these limited objects are not of the same type as the original objects, so the formatting system treated them differently.

Tip

You try it!

Use the Get-Member cmdlet to verify that the type of the objects change slightly when you use the –Property parameter of Select-Object.

Retrieving the values of a single property

Sometimes, you want to get the values of a single property of a set of objects. For instance, if you wanted to get the display names of all of the services installed on your computer, you might try to do something like this:

This is close to what you were looking for, but instead of getting a bunch of names (strings), you got a bunch of objects with the DisplayName properties. A hint that this is what happened is seen by the heading (and underline) of DisplayName. You can also verify this using the Get-Member cmdlet:

In order to just get the values and not objects, you need to use the –ExpandProperty parameter. Unlike the –Property parameter, you can only specify a single property with –ExpandProperty, and the output is a list of raw values. Notice that with –ExpandProperty, the column heading is gone:

We can also verify using Get-Member that we just got strings instead of objects with a DisplayName property:

There are a few other parameters for Select-Object, but they will be less commonly used than the ones listed here.

The Measure-Object cmdlet has a simple function. It calculates statistics based on the objects in the pipeline. Its most basic form takes no parameters, and simply counts the objects that are in the pipeline.

To count the files in c:\temp and its subfolders, you could write:

Dir c:\temp –recurse –file | Measure-Object

The output shows the count, and also some other properties that give a hint about the other uses of the cmdlet. To populate these other fields, you will need to provide the name of the property that is used to calculate them and also specify which field(s) you want to calculate. The calculations are specified using the –Sum, -Minimum, -Maximum, and –Average switches.

For instance, to add up (sum) the lengths of the files in the C:\Windows directory, you could issue this command:

Dir c:\Windows | Measure-Object –Property Length –Sum

The Group-Object cmdlet divides the objects in the pipeline into distinct sets based on a property or a set of properties. For instance, we can categorize the files in a folder by their extensions using Group-Object like this:

You will notice in the output that PowerShell has provided the count of items in each set, the value of the property (Extension) that labels the set, and a property called Group, which contains all of the original objects that were on the pipeline that ended up in the set. If you have used the GROUP BY clause in SQL and are used to losing the original information when you group, you'll be pleased to know that PowerShell retains those objects in their original state in the Group property of the output.

If you don't need the objects and are simply concerned with what the counts are, you can use the –NoElement switch, which causes the Group property to be omitted.

You're not limited to grouping by a single property either. If you want to see files grouped by mode (read-only, archive, etc.) and extension, you can simply list both properties.

Note that the Name property of each set is now a list of two values corresponding to the two properties defining the group.

The Group-Object cmdlet can be useful to summarize the objects, but you will probably not use it nearly as much as Sort-Object, Where-Object, and Select-Object.

The Select-Object cmdlet is a versatile cmdlet that you will find yourself using often. There are three main ways that it is used:

Limiting the number of objects returned

Sometimes, you just want to see a few of the objects that are in the pipeline. To accomplish this, you can use the -First, -Last, and -Skip parameters. The -First parameter indicates that you want to see a particular number of objects from the beginning of the list of objects in the pipeline. Similarly, the -Last parameter selects objects from the end of the list of objects in the pipeline.

For instance, getting the first two processes in the list from Get-Process is simple:

Since we didn't use Sort-Object to force the order of the objects in the pipeline, we don't know that these are the first alphabetically, but they were the first two that were output from Get-Process.

You can use –Skip to cause a certain number of objects to be bypassed before returning the objects. It can be used by itself to output the rest of the objects after the skipped ones, or in conjunction with –First or –Last to return all but the beginning or end of the list of objects. As an example, -Skip can be used to skip over header lines when reading a file using the Get-Content cmdlet.

Limiting the properties of the objects returned

Sometimes, the objects in the pipeline have more properties than you need. To select only certain properties from the list of objects in the pipeline, you can use the –Property parameter with a list of properties. For instance, to get only the Name, Extension, and Length from the directory listing, you could do something like this:

I used the –First parameter as well to save some space in the output, but the important thing is that we only got the three properties that we asked for.

Note that, here, the first two objects in the pipeline were directories, and directory objects don't have a length property. PowerShell provides an empty value of $null for missing properties like this. Also, note that these objects weren't formatted like a directory listing. We'll talk about formatting in detail in the next chapter, but for now, you should just know that these limited objects are not of the same type as the original objects, so the formatting system treated them differently.

Tip

You try it!

Use the Get-Member cmdlet to verify that the type of the objects change slightly when you use the –Property parameter of Select-Object.

Retrieving the values of a single property

Sometimes, you want to get the values of a single property of a set of objects. For instance, if you wanted to get the display names of all of the services installed on your computer, you might try to do something like this:

This is close to what you were looking for, but instead of getting a bunch of names (strings), you got a bunch of objects with the DisplayName properties. A hint that this is what happened is seen by the heading (and underline) of DisplayName. You can also verify this using the Get-Member cmdlet:

In order to just get the values and not objects, you need to use the –ExpandProperty parameter. Unlike the –Property parameter, you can only specify a single property with –ExpandProperty, and the output is a list of raw values. Notice that with –ExpandProperty, the column heading is gone:

We can also verify using Get-Member that we just got strings instead of objects with a DisplayName property:

There are a few other parameters for Select-Object, but they will be less commonly used than the ones listed here.

The Measure-Object cmdlet has a simple function. It calculates statistics based on the objects in the pipeline. Its most basic form takes no parameters, and simply counts the objects that are in the pipeline.

To count the files in c:\temp and its subfolders, you could write:

Dir c:\temp –recurse –file | Measure-Object

The output shows the count, and also some other properties that give a hint about the other uses of the cmdlet. To populate these other fields, you will need to provide the name of the property that is used to calculate them and also specify which field(s) you want to calculate. The calculations are specified using the –Sum, -Minimum, -Maximum, and –Average switches.

For instance, to add up (sum) the lengths of the files in the C:\Windows directory, you could issue this command:

Dir c:\Windows | Measure-Object –Property Length –Sum

The Group-Object cmdlet divides the objects in the pipeline into distinct sets based on a property or a set of properties. For instance, we can categorize the files in a folder by their extensions using Group-Object like this:

You will notice in the output that PowerShell has provided the count of items in each set, the value of the property (Extension) that labels the set, and a property called Group, which contains all of the original objects that were on the pipeline that ended up in the set. If you have used the GROUP BY clause in SQL and are used to losing the original information when you group, you'll be pleased to know that PowerShell retains those objects in their original state in the Group property of the output.

If you don't need the objects and are simply concerned with what the counts are, you can use the –NoElement switch, which causes the Group property to be omitted.

You're not limited to grouping by a single property either. If you want to see files grouped by mode (read-only, archive, etc.) and extension, you can simply list both properties.

Note that the Name property of each set is now a list of two values corresponding to the two properties defining the group.

The Group-Object cmdlet can be useful to summarize the objects, but you will probably not use it nearly as much as Sort-Object, Where-Object, and Select-Object.

The Measure-Object cmdlet has a simple function. It calculates statistics based on the objects in the pipeline. Its most basic form takes no parameters, and simply counts the objects that are in the pipeline.

To count the files in c:\temp and its subfolders, you could write:

Dir c:\temp –recurse –file | Measure-Object

The output shows the count, and also some other properties that give a hint about the other uses of the cmdlet. To populate these other fields, you will need to provide the name of the property that is used to calculate them and also specify which field(s) you want to calculate. The calculations are specified using the –Sum, -Minimum, -Maximum, and –Average switches.

For instance, to add up (sum) the lengths of the files in the C:\Windows directory, you could issue this command:

Dir c:\Windows | Measure-Object –Property Length –Sum

The Group-Object cmdlet divides the objects in the pipeline into distinct sets based on a property or a set of properties. For instance, we can categorize the files in a folder by their extensions using Group-Object like this:

You will notice in the output that PowerShell has provided the count of items in each set, the value of the property (Extension) that labels the set, and a property called Group, which contains all of the original objects that were on the pipeline that ended up in the set. If you have used the GROUP BY clause in SQL and are used to losing the original information when you group, you'll be pleased to know that PowerShell retains those objects in their original state in the Group property of the output.

If you don't need the objects and are simply concerned with what the counts are, you can use the –NoElement switch, which causes the Group property to be omitted.

You're not limited to grouping by a single property either. If you want to see files grouped by mode (read-only, archive, etc.) and extension, you can simply list both properties.

Note that the Name property of each set is now a list of two values corresponding to the two properties defining the group.

The Group-Object cmdlet can be useful to summarize the objects, but you will probably not use it nearly as much as Sort-Object, Where-Object, and Select-Object.

The Measure-Object cmdlet has a simple function. It calculates statistics based on the objects in the pipeline. Its most basic form takes no parameters, and simply counts the objects that are in the pipeline.

To count the files in c:\temp and its subfolders, you could write:

Dir c:\temp –recurse –file | Measure-Object

The output shows the count, and also some other properties that give a hint about the other uses of the cmdlet. To populate these other fields, you will need to provide the name of the property that is used to calculate them and also specify which field(s) you want to calculate. The calculations are specified using the –Sum, -Minimum, -Maximum, and –Average switches.

For instance, to add up (sum) the lengths of the files in the C:\Windows directory, you could issue this command:

Dir c:\Windows | Measure-Object –Property Length –Sum

The Group-Object cmdlet divides the objects in the pipeline into distinct sets based on a property or a set of properties. For instance, we can categorize the files in a folder by their extensions using Group-Object like this:

You will notice in the output that PowerShell has provided the count of items in each set, the value of the property (Extension) that labels the set, and a property called Group, which contains all of the original objects that were on the pipeline that ended up in the set. If you have used the GROUP BY clause in SQL and are used to losing the original information when you group, you'll be pleased to know that PowerShell retains those objects in their original state in the Group property of the output.

If you don't need the objects and are simply concerned with what the counts are, you can use the –NoElement switch, which causes the Group property to be omitted.

You're not limited to grouping by a single property either. If you want to see files grouped by mode (read-only, archive, etc.) and extension, you can simply list both properties.

Note that the Name property of each set is now a list of two values corresponding to the two properties defining the group.

The Group-Object cmdlet can be useful to summarize the objects, but you will probably not use it nearly as much as Sort-Object, Where-Object, and Select-Object.

The Measure-Object cmdlet has a simple function. It calculates statistics based on the objects in the pipeline. Its most basic form takes no parameters, and simply counts the objects that are in the pipeline.

To count the files in c:\temp and its subfolders, you could write:

Dir c:\temp –recurse –file | Measure-Object

The output shows the count, and also some other properties that give a hint about the other uses of the cmdlet. To populate these other fields, you will need to provide the name of the property that is used to calculate them and also specify which field(s) you want to calculate. The calculations are specified using the –Sum, -Minimum, -Maximum, and –Average switches.

For instance, to add up (sum) the lengths of the files in the C:\Windows directory, you could issue this command:

Dir c:\Windows | Measure-Object –Property Length –Sum

The Group-Object cmdlet divides the objects in the pipeline into distinct sets based on a property or a set of properties. For instance, we can categorize the files in a folder by their extensions using Group-Object like this:

You will notice in the output that PowerShell has provided the count of items in each set, the value of the property (Extension) that labels the set, and a property called Group, which contains all of the original objects that were on the pipeline that ended up in the set. If you have used the GROUP BY clause in SQL and are used to losing the original information when you group, you'll be pleased to know that PowerShell retains those objects in their original state in the Group property of the output.

If you don't need the objects and are simply concerned with what the counts are, you can use the –NoElement switch, which causes the Group property to be omitted.

You're not limited to grouping by a single property either. If you want to see files grouped by mode (read-only, archive, etc.) and extension, you can simply list both properties.

Note that the Name property of each set is now a list of two values corresponding to the two properties defining the group.

The Group-Object cmdlet can be useful to summarize the objects, but you will probably not use it nearly as much as Sort-Object, Where-Object, and Select-Object.

The Measure-Object cmdlet has a simple function. It calculates statistics based on the objects in the pipeline. Its most basic form takes no parameters, and simply counts the objects that are in the pipeline.

To count the files in c:\temp and its subfolders, you could write:

Dir c:\temp –recurse –file | Measure-Object

The output shows the count, and also some other properties that give a hint about the other uses of the cmdlet. To populate these other fields, you will need to provide the name of the property that is used to calculate them and also specify which field(s) you want to calculate. The calculations are specified using the –Sum, -Minimum, -Maximum, and –Average switches.

For instance, to add up (sum) the lengths of the files in the C:\Windows directory, you could issue this command:

Dir c:\Windows | Measure-Object –Property Length –Sum

The Group-Object cmdlet divides the objects in the pipeline into distinct sets based on a property or a set of properties. For instance, we can categorize the files in a folder by their extensions using Group-Object like this:

You will notice in the output that PowerShell has provided the count of items in each set, the value of the property (Extension) that labels the set, and a property called Group, which contains all of the original objects that were on the pipeline that ended up in the set. If you have used the GROUP BY clause in SQL and are used to losing the original information when you group, you'll be pleased to know that PowerShell retains those objects in their original state in the Group property of the output.

If you don't need the objects and are simply concerned with what the counts are, you can use the –NoElement switch, which causes the Group property to be omitted.

You're not limited to grouping by a single property either. If you want to see files grouped by mode (read-only, archive, etc.) and extension, you can simply list both properties.

Note that the Name property of each set is now a list of two values corresponding to the two properties defining the group.

The Group-Object cmdlet can be useful to summarize the objects, but you will probably not use it nearly as much as Sort-Object, Where-Object, and Select-Object.

The Group-Object cmdlet divides the objects in the pipeline into distinct sets based on a property or a set of properties. For instance, we can categorize the files in a folder by their extensions using Group-Object like this:

You will notice in the output that PowerShell has provided the count of items in each set, the value of the property (Extension) that labels the set, and a property called Group, which contains all of the original objects that were on the pipeline that ended up in the set. If you have used the GROUP BY clause in SQL and are used to losing the original information when you group, you'll be pleased to know that PowerShell retains those objects in their original state in the Group property of the output.

If you don't need the objects and are simply concerned with what the counts are, you can use the –NoElement switch, which causes the Group property to be omitted.

You're not limited to grouping by a single property either. If you want to see files grouped by mode (read-only, archive, etc.) and extension, you can simply list both properties.

Note that the Name property of each set is now a list of two values corresponding to the two properties defining the group.

The Group-Object cmdlet can be useful to summarize the objects, but you will probably not use it nearly as much as Sort-Object, Where-Object, and Select-Object.

In $PSHOME, there are files whose names end with format.ps1xml. These files are XML files that specify the default formatting specifications for many of the types of objects that you will work with in PowerShell. These files are loaded by the host when the PowerShell session starts. If you write your own format files, you can load them using the Update-FormatData cmdlet. The details of writing your own format files are beyond the scope of Module 1, but a quick read through the FileSystem.Format.ps1xml file will make some things clear:

In this file, first, we can see that the formatting is selected by the objects of the System.IO.DirectoryInfo and System.IO.FileInfo types. Second, the first view specified is grouped by PSParentPath and we can see the properties listed (Mode, LastWriteTime, Length, and Name) in the table format. These two observations match what we see, when we execute the Get-ChildItem cmdlet against a file system path.

Knowing that the type of objects are matched against the formatting specified in the files is part of the equation. The next thing to know is that PowerShell relies on the first object in the pipeline to determine what formatting to apply. If subsequent objects don't "fit" in that format, PowerShell will revert to a list display, listing the property names and values separated by a colon. To illustrate this, we can join two different pipelines together using a semicolon. This will cause the output of both pipelines to be treated as if they were from the same pipeline. The first part of the pipeline is outputting the first item in the root of C: and the second is outputting the first process:

The pipeline we executed outputted a single DirectoryInfo object as well as a process object. PowerShell selected the default, tabular view for the DirectoryInfo object, but the Process object doesn't fit in this format. Thus, the Process object was formatted in a generic way, listing the properties one per line.

If we reverse the pipeline, we'll see that the Process object gets its specified format and the DirectoryInfo object is generically treated:

Another thing that can be confusing is that if we use Select-Object to limit the properties output, the resulting object is no longer of the original type. For example, we execute the following:

Dir | Select-Object –Property Name,Length

Here, we would no longer be outputting the System.IO.FileInfo and System.IO.DirectoryInfo objects, but the Selected.System.IO.FileInfo and Selected.System.IO.DirectoryInfo objects. These new objects would not be selected by the same format files, because the type is different.

If the objects being formatted don't match a format file, one of the rules of formatting says that small objects with four or less properties are formatted as a table. We can verify this using Select-Object as mentioned in the last section to create new objects that don't match the existing format file:

As expected, not only do we avoid the grouped format that we saw before for Dir output, but we also got the data in a table since there were only four properties.

Sometimes, we find that the table format that is generated doesn't look very nice. The engine divides the line evenly into the number of columns that are required. It also formats each column according to the type of data in the properties of the first object, left-aligning strings and right-aligning numbers. Look at the output of the two commands in the following screenshot, and you will see that the spacing of both of the tables is looking somewhat ridiculous. We'll see later in the chapter what we can do to improve this situation, but for now, we just need to be aware that sometimes default formatting is less than perfect:

Another issue with formatting in a table is that sometimes the properties don't fit very well in the columns. When this happens, PowerShell will truncate the value and end the display with an ellipsis (...):

Objects that are larger than four properties are placed into what PowerShell calls a list format, placing each property of each object in a separate line, and separating the property name from the property value with a colon. We saw this format earlier when an object did not fit in the format selected by the first object in the pipeline.

Continuing the examples using Dir, we can see this format in action. Adding a fifth property to the Select-Object cmdlet causes the output to be formatted as a list:

List formats can seem cleaner than tabular formats because there is less room for issues with column widths and left and right justification. On the other hand, the output is spread over a lot more lines and is harder to scan visually.

In $PSHOME, there are files whose names end with format.ps1xml. These files are XML files that specify the default formatting specifications for many of the types of objects that you will work with in PowerShell. These files are loaded by the host when the PowerShell session starts. If you write your own format files, you can load them using the Update-FormatData cmdlet. The details of writing your own format files are beyond the scope of Module 1, but a quick read through the FileSystem.Format.ps1xml file will make some things clear:

In this file, first, we can see that the formatting is selected by the objects of the System.IO.DirectoryInfo and System.IO.FileInfo types. Second, the first view specified is grouped by PSParentPath and we can see the properties listed (Mode, LastWriteTime, Length, and Name) in the table format. These two observations match what we see, when we execute the Get-ChildItem cmdlet against a file system path.

Knowing that the type of objects are matched against the formatting specified in the files is part of the equation. The next thing to know is that PowerShell relies on the first object in the pipeline to determine what formatting to apply. If subsequent objects don't "fit" in that format, PowerShell will revert to a list display, listing the property names and values separated by a colon. To illustrate this, we can join two different pipelines together using a semicolon. This will cause the output of both pipelines to be treated as if they were from the same pipeline. The first part of the pipeline is outputting the first item in the root of C: and the second is outputting the first process:

The pipeline we executed outputted a single DirectoryInfo object as well as a process object. PowerShell selected the default, tabular view for the DirectoryInfo object, but the Process object doesn't fit in this format. Thus, the Process object was formatted in a generic way, listing the properties one per line.

If we reverse the pipeline, we'll see that the Process object gets its specified format and the DirectoryInfo object is generically treated:

Another thing that can be confusing is that if we use Select-Object to limit the properties output, the resulting object is no longer of the original type. For example, we execute the following:

Dir | Select-Object –Property Name,Length

Here, we would no longer be outputting the System.IO.FileInfo and System.IO.DirectoryInfo objects, but the Selected.System.IO.FileInfo and Selected.System.IO.DirectoryInfo objects. These new objects would not be selected by the same format files, because the type is different.

If the objects being formatted don't match a format file, one of the rules of formatting says that small objects with four or less properties are formatted as a table. We can verify this using Select-Object as mentioned in the last section to create new objects that don't match the existing format file:

As expected, not only do we avoid the grouped format that we saw before for Dir output, but we also got the data in a table since there were only four properties.

Sometimes, we find that the table format that is generated doesn't look very nice. The engine divides the line evenly into the number of columns that are required. It also formats each column according to the type of data in the properties of the first object, left-aligning strings and right-aligning numbers. Look at the output of the two commands in the following screenshot, and you will see that the spacing of both of the tables is looking somewhat ridiculous. We'll see later in the chapter what we can do to improve this situation, but for now, we just need to be aware that sometimes default formatting is less than perfect:

Another issue with formatting in a table is that sometimes the properties don't fit very well in the columns. When this happens, PowerShell will truncate the value and end the display with an ellipsis (...):

Objects that are larger than four properties are placed into what PowerShell calls a list format, placing each property of each object in a separate line, and separating the property name from the property value with a colon. We saw this format earlier when an object did not fit in the format selected by the first object in the pipeline.

Continuing the examples using Dir, we can see this format in action. Adding a fifth property to the Select-Object cmdlet causes the output to be formatted as a list:

List formats can seem cleaner than tabular formats because there is less room for issues with column widths and left and right justification. On the other hand, the output is spread over a lot more lines and is harder to scan visually.

Knowing that the type of objects are matched against the formatting specified in the files is part of the equation. The next thing to know is that PowerShell relies on the first object in the pipeline to determine what formatting to apply. If subsequent objects don't "fit" in that format, PowerShell will revert to a list display, listing the property names and values separated by a colon. To illustrate this, we can join two different pipelines together using a semicolon. This will cause the output of both pipelines to be treated as if they were from the same pipeline. The first part of the pipeline is outputting the first item in the root of C: and the second is outputting the first process:

The pipeline we executed outputted a single DirectoryInfo object as well as a process object. PowerShell selected the default, tabular view for the DirectoryInfo object, but the Process object doesn't fit in this format. Thus, the Process object was formatted in a generic way, listing the properties one per line.

If we reverse the pipeline, we'll see that the Process object gets its specified format and the DirectoryInfo object is generically treated:

Another thing that can be confusing is that if we use Select-Object to limit the properties output, the resulting object is no longer of the original type. For example, we execute the following:

Dir | Select-Object –Property Name,Length

Here, we would no longer be outputting the System.IO.FileInfo and System.IO.DirectoryInfo objects, but the Selected.System.IO.FileInfo and Selected.System.IO.DirectoryInfo objects. These new objects would not be selected by the same format files, because the type is different.

If the objects being formatted don't match a format file, one of the rules of formatting says that small objects with four or less properties are formatted as a table. We can verify this using Select-Object as mentioned in the last section to create new objects that don't match the existing format file:

As expected, not only do we avoid the grouped format that we saw before for Dir output, but we also got the data in a table since there were only four properties.

Sometimes, we find that the table format that is generated doesn't look very nice. The engine divides the line evenly into the number of columns that are required. It also formats each column according to the type of data in the properties of the first object, left-aligning strings and right-aligning numbers. Look at the output of the two commands in the following screenshot, and you will see that the spacing of both of the tables is looking somewhat ridiculous. We'll see later in the chapter what we can do to improve this situation, but for now, we just need to be aware that sometimes default formatting is less than perfect:

Another issue with formatting in a table is that sometimes the properties don't fit very well in the columns. When this happens, PowerShell will truncate the value and end the display with an ellipsis (...):

Objects that are larger than four properties are placed into what PowerShell calls a list format, placing each property of each object in a separate line, and separating the property name from the property value with a colon. We saw this format earlier when an object did not fit in the format selected by the first object in the pipeline.

Continuing the examples using Dir, we can see this format in action. Adding a fifth property to the Select-Object cmdlet causes the output to be formatted as a list:

List formats can seem cleaner than tabular formats because there is less room for issues with column widths and left and right justification. On the other hand, the output is spread over a lot more lines and is harder to scan visually.

If the objects being formatted don't match a format file, one of the rules of formatting says that small objects with four or less properties are formatted as a table. We can verify this using Select-Object as mentioned in the last section to create new objects that don't match the existing format file:

As expected, not only do we avoid the grouped format that we saw before for Dir output, but we also got the data in a table since there were only four properties.

Sometimes, we find that the table format that is generated doesn't look very nice. The engine divides the line evenly into the number of columns that are required. It also formats each column according to the type of data in the properties of the first object, left-aligning strings and right-aligning numbers. Look at the output of the two commands in the following screenshot, and you will see that the spacing of both of the tables is looking somewhat ridiculous. We'll see later in the chapter what we can do to improve this situation, but for now, we just need to be aware that sometimes default formatting is less than perfect:

Another issue with formatting in a table is that sometimes the properties don't fit very well in the columns. When this happens, PowerShell will truncate the value and end the display with an ellipsis (...):

Objects that are larger than four properties are placed into what PowerShell calls a list format, placing each property of each object in a separate line, and separating the property name from the property value with a colon. We saw this format earlier when an object did not fit in the format selected by the first object in the pipeline.

Continuing the examples using Dir, we can see this format in action. Adding a fifth property to the Select-Object cmdlet causes the output to be formatted as a list:

List formats can seem cleaner than tabular formats because there is less room for issues with column widths and left and right justification. On the other hand, the output is spread over a lot more lines and is harder to scan visually.

Objects that are larger than four properties are placed into what PowerShell calls a list format, placing each property of each object in a separate line, and separating the property name from the property value with a colon. We saw this format earlier when an object did not fit in the format selected by the first object in the pipeline.

Continuing the examples using Dir, we can see this format in action. Adding a fifth property to the Select-Object cmdlet causes the output to be formatted as a list:

List formats can seem cleaner than tabular formats because there is less room for issues with column widths and left and right justification. On the other hand, the output is spread over a lot more lines and is harder to scan visually.

The two most commonly used formatting cmdlets are Format-Table and Format-List. As their names suggest, they force the formatting system to use either a table or a list format for the objects, irrespective of the number of properties or the type-related formatting files that might be present. Each of the cmdlets has a –Property parameter that takes a list of properties to be included. A couple of quick examples should make the basic usage clear.

First, we can use Format-List with the long property value example we saw earlier, which led to an unusable table, to see how this would look like as a list:

Clearly, the output makes a lot more sense as a list.

Also, we can use Format-Table to output a series of objects that would, normally, have been formatted as a list because they have more than four properties. Since we know the properties in this case are numeric, formatting as a table is reasonable:

In this case, we still have some open spaces, so we can utilize the –AutoSize switch parameter to improve the output format even more. AutoSize tells the formatting system to look at all the values in all the columns before deciding on the column sizes (instead of dividing the line evenly):

If the number of objects is not very high, using AutoSize can make the tables much nicer to look at. The –AutoSize switch will also help the awkward looking tables, which we saw with two columns, either at the margins or crowded at the center of the page:

The two most commonly used formatting cmdlets are Format-Table and Format-List. As their names suggest, they force the formatting system to use either a table or a list format for the objects, irrespective of the number of properties or the type-related formatting files that might be present. Each of the cmdlets has a –Property parameter that takes a list of properties to be included. A couple of quick examples should make the basic usage clear.

First, we can use Format-List with the long property value example we saw earlier, which led to an unusable table, to see how this would look like as a list:

Clearly, the output makes a lot more sense as a list.

Also, we can use Format-Table to output a series of objects that would, normally, have been formatted as a list because they have more than four properties. Since we know the properties in this case are numeric, formatting as a table is reasonable:

In this case, we still have some open spaces, so we can utilize the –AutoSize switch parameter to improve the output format even more. AutoSize tells the formatting system to look at all the values in all the columns before deciding on the column sizes (instead of dividing the line evenly):

If the number of objects is not very high, using AutoSize can make the tables much nicer to look at. The –AutoSize switch will also help the awkward looking tables, which we saw with two columns, either at the margins or crowded at the center of the page:

The most simple logic statement is the If statement. The If statement allows you to have some code executed, if and only if a particular condition is met. In its simplest form, the If statement includes a condition in parentheses and a scriptblock to be executed when the condition is true:

If there is another condition that should be executed if the first condition is false, you can include an Else clause:

If you have multiple conditions to test, there is an ElseIf clause as well. Here's an example of its use:

The most common way to loop in PowerShell is the ForEach statement. ForEach causes a scriptblock to be executed for each item in a collection. The ForEach statement lets you name the placeholder that is used to refer to the individual items in the collection. The syntax for the ForEach statement looks as follows:

ForEach ($placeholder in $collection){
  #Code goes here
}

As an example, we can display the extensions of all of the files in a folder using ForEach:

If you remember from Chapter 4, Life on the Assembly Line there is also a ForEach-Object cmdlet that works in a pipeline and executes a scriptblock for each item in the pipeline. To make things even more confusing, ForEach-Object has an alias called ForEach. It's easy to get confused between the ForEach statement and the ForEach-Object cmdlet, but remember that the ForEach statement does not work in a pipeline and lets you name the placeholder, so if it's in a pipeline, it has to be the ForEach-Object cmdlet.

There are other statements that can be used to structure scripts, but If and ForEach are by far the most common. If you need to use others, they are well documented in PowerShell's awesome help content.

For quick reference, some of the other statements include the following:

The most simple logic statement is the If statement. The If statement allows you to have some code executed, if and only if a particular condition is met. In its simplest form, the If statement includes a condition in parentheses and a scriptblock to be executed when the condition is true:

If there is another condition that should be executed if the first condition is false, you can include an Else clause:

If you have multiple conditions to test, there is an ElseIf clause as well. Here's an example of its use:

The most common way to loop in PowerShell is the ForEach statement. ForEach causes a scriptblock to be executed for each item in a collection. The ForEach statement lets you name the placeholder that is used to refer to the individual items in the collection. The syntax for the ForEach statement looks as follows:

ForEach ($placeholder in $collection){
  #Code goes here
}

As an example, we can display the extensions of all of the files in a folder using ForEach:

If you remember from Chapter 4, Life on the Assembly Line there is also a ForEach-Object cmdlet that works in a pipeline and executes a scriptblock for each item in the pipeline. To make things even more confusing, ForEach-Object has an alias called ForEach. It's easy to get confused between the ForEach statement and the ForEach-Object cmdlet, but remember that the ForEach statement does not work in a pipeline and lets you name the placeholder, so if it's in a pipeline, it has to be the ForEach-Object cmdlet.

There are other statements that can be used to structure scripts, but If and ForEach are by far the most common. If you need to use others, they are well documented in PowerShell's awesome help content.

For quick reference, some of the other statements include the following:

The most common way to loop in PowerShell is the ForEach statement. ForEach causes a scriptblock to be executed for each item in a collection. The ForEach statement lets you name the placeholder that is used to refer to the individual items in the collection. The syntax for the ForEach statement looks as follows:

ForEach ($placeholder in $collection){
  #Code goes here
}

As an example, we can display the extensions of all of the files in a folder using ForEach:

If you remember from Chapter 4, Life on the Assembly Line there is also a ForEach-Object cmdlet that works in a pipeline and executes a scriptblock for each item in the pipeline. To make things even more confusing, ForEach-Object has an alias called ForEach. It's easy to get confused between the ForEach statement and the ForEach-Object cmdlet, but remember that the ForEach statement does not work in a pipeline and lets you name the placeholder, so if it's in a pipeline, it has to be the ForEach-Object cmdlet.

There are other statements that can be used to structure scripts, but If and ForEach are by far the most common. If you need to use others, they are well documented in PowerShell's awesome help content.

For quick reference, some of the other statements include the following:

There are other statements that can be used to structure scripts, but If and ForEach are by far the most common. If you need to use others, they are well documented in PowerShell's awesome help content.

For quick reference, some of the other statements include the following:

Something else you might have noticed in this example is that we have specified that both the parameters have to be strings. It's hard to test this, since anything in the command-line is already a string. Let's write a function to output the average of two integers:

The function works if you pass numeric arguments, but passing strings (such as orange and apple) causes an error. If you read the error message, you can see that PowerShell tried to figure out how to change "orange" into a number, but couldn't come up with a transformation that works. PowerShell has a very versatile parameter binding mechanism that attempts a number of methods to transform the arguments you pass into the type of parameters you have specified.

Besides using types like string and int, you can also use the switch type, which indicates a parameter that is either present or absent. We've seen switch parameters in cmdlets, such as the –Recurse switch parameter for Get-ChildItem. Remember that you don't specify an argument to a switch parameter. You either supply the parameter (such as –Recurse) or you don't. Switch parameters allow for easy on/off or true/false input. The parameter can be tested easily in an if statement like this:

Something else you might have noticed in this example is that we have specified that both the parameters have to be strings. It's hard to test this, since anything in the command-line is already a string. Let's write a function to output the average of two integers:

The function works if you pass numeric arguments, but passing strings (such as orange and apple) causes an error. If you read the error message, you can see that PowerShell tried to figure out how to change "orange" into a number, but couldn't come up with a transformation that works. PowerShell has a very versatile parameter binding mechanism that attempts a number of methods to transform the arguments you pass into the type of parameters you have specified.

Besides using types like string and int, you can also use the switch type, which indicates a parameter that is either present or absent. We've seen switch parameters in cmdlets, such as the –Recurse switch parameter for Get-ChildItem. Remember that you don't specify an argument to a switch parameter. You either supply the parameter (such as –Recurse) or you don't. Switch parameters allow for easy on/off or true/false input. The parameter can be tested easily in an if statement like this:

Besides using types like string and int, you can also use the switch type, which indicates a parameter that is either present or absent. We've seen switch parameters in cmdlets, such as the –Recurse switch parameter for Get-ChildItem. Remember that you don't specify an argument to a switch parameter. You either supply the parameter (such as –Recurse) or you don't. Switch parameters allow for easy on/off or true/false input. The parameter can be tested easily in an if statement like this:

The key to controlling which parts of a module are visible is to know the default visibility and how to use the Export-ModuleMember cmdlet.

By default, a module does the following:

If you don't like one of these, you can override it using the Export-ModuleMember cmdlet. This cmdlet has three parameters called -Function, -Variable, and –Alias, which let you list specifically which members (functions, variables, and aliases) you want to be exported. Since we are fine with the variable not being exported, and only want the two area functions exported, we can add this command at the end of the module to get the required configuration:

Export-ModuleMember –Function Get-SquareArea,Get-CircleArea

Export-ModuleMember –variable Pi

The key to controlling which parts of a module are visible is to know the default visibility and how to use the Export-ModuleMember cmdlet.

By default, a module does the following:

If you don't like one of these, you can override it using the Export-ModuleMember cmdlet. This cmdlet has three parameters called -Function, -Variable, and –Alias, which let you list specifically which members (functions, variables, and aliases) you want to be exported. Since we are fine with the variable not being exported, and only want the two area functions exported, we can add this command at the end of the module to get the required configuration:

Export-ModuleMember –Function Get-SquareArea,Get-CircleArea

Export-ModuleMember –variable Pi

While script modules are an improvement over dot-sourcing script files, manifest modules take modules to a new level entirely. A module manifest is a configuration file for a module that lets you provide information about the module and gives you control over what happens when the module is loaded. The information you can provide includes things such as the author, company, copyright date, and a GUID identifier for the module. You can specify requirements for the module, such as the minimum PowerShell version or CLR version required. You also can list the functions, aliases, and variables to be exported from your module.

A benefit of using module manifests is that it is much easier for PowerShell to scan a manifest than to parse a script module file. With PowerShell 3.0, and the recent versions of Windows and Windows Server, the number of delivered modules is very large, and being able to see the contents of a module without parsing hundreds of files is a tremendous time-saver. Manifests also allow you to specify any dependencies for your module, including files that should be executed or loaded when the module is imported.

PowerShell includes a cmdlet called New-ModuleManifest, which creates a .psd1 file for you. Here is the file created by New-ModuleManifest testmanifest.psd1:

While script modules are an improvement over dot-sourcing script files, manifest modules take modules to a new level entirely. A module manifest is a configuration file for a module that lets you provide information about the module and gives you control over what happens when the module is loaded. The information you can provide includes things such as the author, company, copyright date, and a GUID identifier for the module. You can specify requirements for the module, such as the minimum PowerShell version or CLR version required. You also can list the functions, aliases, and variables to be exported from your module.

A benefit of using module manifests is that it is much easier for PowerShell to scan a manifest than to parse a script module file. With PowerShell 3.0, and the recent versions of Windows and Windows Server, the number of delivered modules is very large, and being able to see the contents of a module without parsing hundreds of files is a tremendous time-saver. Manifests also allow you to specify any dependencies for your module, including files that should be executed or loaded when the module is imported.

PowerShell includes a cmdlet called New-ModuleManifest, which creates a .psd1 file for you. Here is the file created by New-ModuleManifest testmanifest.psd1:

If your workplace is anything like mine, you probably work with people who want reports about what is going on. Writing "real" reports in SQL Server reporting services is an option if your data is accessible to SQL server, but they take a while to write and deploy. Obviously, there are reporting packages that you can use as well, such as Crystal Reports, but they can be expensive and take time to write and deploy a report. Most people in IT, though, are fine with Excel as a document format and can work with the data in Excel to create a report.

Outputting objects to CSV files in PowerShell is very simple. The Export-CSV cmdlet looks at the properties of the first object in the pipeline and creates a CSV file with a header row containing the names of these properties. It writes the values of these properties in successive lines of the file. Since it uses all the properties of the (first) object, you will probably want to "narrow" down the object using Select-Object and the –Property parameter to limit the properties that show up in your CSV file.

For example, if you wanted to create a file with the names and lengths of the files in a folder, you could use the following code:

You can see from the output of the Get-Content cmdlet that there is a line at the top that indicates the type of objects that were output. You can suppress this line by including the –NoTypeInformation switch. You can also see that the column headings and the values are enclosed in quotes and separated by commas. It's possible to change the delimiter to something other than a comma using the –Delimiter parameter, but you don't have the option to suppress the quotes.

You can easily open a CSV file in Excel (or whatever application is associated with CSV files on your system) using the Invoke-Item cmdlet. Invoke-Item performs the default action associated with a particular file. You can think of it as double-clicking on an item in the File Explorer. If you have Excel, the default action for CSV files is to open them in Excel. To easily open the output file we created in the last section, we would use Invoke-Item c:\temp\filelist.csv, and it would pop up looking like a spreadsheet as follows:

At this point, it can be manipulated just like a normal spreadsheet, so it's easy for people who haven't learned PowerShell yet to work with it.

Since PowerShell cmdlets work on objects, it's convenient to be able to read a file as a sequence of objects rather than as strings, like you would from Get-Content. Just as Export-CSV takes objects and writes them to a file, Import-CSV reads a CSV file and outputs objects with the properties that are named in the header.

An easy example to understand would be a CSV file that contains a server list with the name of each server, as well as the type of the server (Web, Database, or File), and whom to contact, if there are problems with each server:

With this CSV file, we can easily read this into a variable using Import-CSV. As Import-CSV creates objects, we can refer to the rows of this CSV file using properties. Getting a summary of our servers using the Group-Object cmdlet is a simple matter:

If your workplace is anything like mine, you probably work with people who want reports about what is going on. Writing "real" reports in SQL Server reporting services is an option if your data is accessible to SQL server, but they take a while to write and deploy. Obviously, there are reporting packages that you can use as well, such as Crystal Reports, but they can be expensive and take time to write and deploy a report. Most people in IT, though, are fine with Excel as a document format and can work with the data in Excel to create a report.

Outputting objects to CSV files in PowerShell is very simple. The Export-CSV cmdlet looks at the properties of the first object in the pipeline and creates a CSV file with a header row containing the names of these properties. It writes the values of these properties in successive lines of the file. Since it uses all the properties of the (first) object, you will probably want to "narrow" down the object using Select-Object and the –Property parameter to limit the properties that show up in your CSV file.

For example, if you wanted to create a file with the names and lengths of the files in a folder, you could use the following code:

You can see from the output of the Get-Content cmdlet that there is a line at the top that indicates the type of objects that were output. You can suppress this line by including the –NoTypeInformation switch. You can also see that the column headings and the values are enclosed in quotes and separated by commas. It's possible to change the delimiter to something other than a comma using the –Delimiter parameter, but you don't have the option to suppress the quotes.

You can easily open a CSV file in Excel (or whatever application is associated with CSV files on your system) using the Invoke-Item cmdlet. Invoke-Item performs the default action associated with a particular file. You can think of it as double-clicking on an item in the File Explorer. If you have Excel, the default action for CSV files is to open them in Excel. To easily open the output file we created in the last section, we would use Invoke-Item c:\temp\filelist.csv, and it would pop up looking like a spreadsheet as follows:

At this point, it can be manipulated just like a normal spreadsheet, so it's easy for people who haven't learned PowerShell yet to work with it.

Since PowerShell cmdlets work on objects, it's convenient to be able to read a file as a sequence of objects rather than as strings, like you would from Get-Content. Just as Export-CSV takes objects and writes them to a file, Import-CSV reads a CSV file and outputs objects with the properties that are named in the header.

An easy example to understand would be a CSV file that contains a server list with the name of each server, as well as the type of the server (Web, Database, or File), and whom to contact, if there are problems with each server:

With this CSV file, we can easily read this into a variable using Import-CSV. As Import-CSV creates objects, we can refer to the rows of this CSV file using properties. Getting a summary of our servers using the Group-Object cmdlet is a simple matter:

You can easily open a CSV file in Excel (or whatever application is associated with CSV files on your system) using the Invoke-Item cmdlet. Invoke-Item performs the default action associated with a particular file. You can think of it as double-clicking on an item in the File Explorer. If you have Excel, the default action for CSV files is to open them in Excel. To easily open the output file we created in the last section, we would use Invoke-Item c:\temp\filelist.csv, and it would pop up looking like a spreadsheet as follows:

At this point, it can be manipulated just like a normal spreadsheet, so it's easy for people who haven't learned PowerShell yet to work with it.

Since PowerShell cmdlets work on objects, it's convenient to be able to read a file as a sequence of objects rather than as strings, like you would from Get-Content. Just as Export-CSV takes objects and writes them to a file, Import-CSV reads a CSV file and outputs objects with the properties that are named in the header.

An easy example to understand would be a CSV file that contains a server list with the name of each server, as well as the type of the server (Web, Database, or File), and whom to contact, if there are problems with each server:

With this CSV file, we can easily read this into a variable using Import-CSV. As Import-CSV creates objects, we can refer to the rows of this CSV file using properties. Getting a summary of our servers using the Group-Object cmdlet is a simple matter:

Since PowerShell cmdlets work on objects, it's convenient to be able to read a file as a sequence of objects rather than as strings, like you would from Get-Content. Just as Export-CSV takes objects and writes them to a file, Import-CSV reads a CSV file and outputs objects with the properties that are named in the header.

An easy example to understand would be a CSV file that contains a server list with the name of each server, as well as the type of the server (Web, Database, or File), and whom to contact, if there are problems with each server:

With this CSV file, we can easily read this into a variable using Import-CSV. As Import-CSV creates objects, we can refer to the rows of this CSV file using properties. Getting a summary of our servers using the Group-Object cmdlet is a simple matter:

In addition to the single greater-than symbol, there are a number of other redirection operators that append (using two greater-than symbols) and combine streams (such as 2>&1, which merges the error stream to the output stream using the numbers found in the table). As there a number of streams and a variety of operators, you should refer to the about_redirection help topic for a complete description.

A final way to redirect output is to use the out-file cmdlet. Unlike the redirect operator, out-file includes an –Encoding parameter that lets you change the encoding. The values for this parameter are the same as the Set-Content cmdlet. The main difference between Set-Content and Out-File is that Out-File accepts pipeline input. So, you will use Out-File as the last command in a pipeline to send the output to a file.

For instance, the redirection we performed with the redirection operator would be expressed using Out-File as follows:

Dir c:\temp | out-file C:\temp\files.txt

I don't know about you, but this is a lot easier for me to read. If you want to append to an existing file, the –Append switch is what you're looking for. You don't get to combine streams as you can with the redirection operators, but for general purpose output redirection, Out-File is a good candidate.

In addition to the single greater-than symbol, there are a number of other redirection operators that append (using two greater-than symbols) and combine streams (such as 2>&1, which merges the error stream to the output stream using the numbers found in the table). As there a number of streams and a variety of operators, you should refer to the about_redirection help topic for a complete description.

A final way to redirect output is to use the out-file cmdlet. Unlike the redirect operator, out-file includes an –Encoding parameter that lets you change the encoding. The values for this parameter are the same as the Set-Content cmdlet. The main difference between Set-Content and Out-File is that Out-File accepts pipeline input. So, you will use Out-File as the last command in a pipeline to send the output to a file.

For instance, the redirection we performed with the redirection operator would be expressed using Out-File as follows:

Dir c:\temp | out-file C:\temp\files.txt

I don't know about you, but this is a lot easier for me to read. If you want to append to an existing file, the –Append switch is what you're looking for. You don't get to combine streams as you can with the redirection operators, but for general purpose output redirection, Out-File is a good candidate.

A final way to redirect output is to use the out-file cmdlet. Unlike the redirect operator, out-file includes an –Encoding parameter that lets you change the encoding. The values for this parameter are the same as the Set-Content cmdlet. The main difference between Set-Content and Out-File is that Out-File accepts pipeline input. So, you will use Out-File as the last command in a pipeline to send the output to a file.

For instance, the redirection we performed with the redirection operator would be expressed using Out-File as follows:

Dir c:\temp | out-file C:\temp\files.txt

I don't know about you, but this is a lot easier for me to read. If you want to append to an existing file, the –Append switch is what you're looking for. You don't get to combine streams as you can with the redirection operators, but for general purpose output redirection, Out-File is a good candidate.

With Win32_ComputerSystem, we didn't have to worry about which instance was returned because there was only one. The next class we looked at was Win32_Service, which returned multiple objects, one for each service on the computer. In order to select specific instances, we can use the –Filter parameter.

Since WMI covers thousands of different kinds of classes, it would be impossible for Get-WMIObject to have specific parameters to help us narrow down which objects we would like to see. For instance, if we use Get-Service to look at services, we can use the –Name parameter to filter by name. Not all WMI objects have a name property, so it wouldn't make sense to have a parameter to filter by this single property. The solution is to have a query language called WMI Query Language (WQL), similar to SQL, and a single parameter called –Filter that takes the WHERE clause of the WQL query in order to filter the objects.

WQL syntax is very simple to use, and is very similar to SQL. In the WQL filter, you can use the property names of classes, constants, and operators to build the conditions you are looking for. For example, to return only the AdobeARMService instance from the Win32_Service class, you could use a filter of "Name='AdobeARMService'". Note that I have used double quotes around the filter and single quotes around the string value of the Name property. The full Get-WMIObject statement and output looks as follows:

Filters can be more complex as well. Consider the Win32_LogicalDisk class, which contains an instance for each drive on the local computer:

If we wanted to list all the drives that had less than 10GB free and didn't care about the removable, we could use a filter as follows:

 -Filter "DriveType=3 and FreeSpace< 10737418240"

Here, you can see that I have calculated the value of 10GB because WQL doesn't understand units, and also, I have used a variable to hold the filter in order to keep the line shorter.

With Win32_ComputerSystem, we didn't have to worry about which instance was returned because there was only one. The next class we looked at was Win32_Service, which returned multiple objects, one for each service on the computer. In order to select specific instances, we can use the –Filter parameter.

Since WMI covers thousands of different kinds of classes, it would be impossible for Get-WMIObject to have specific parameters to help us narrow down which objects we would like to see. For instance, if we use Get-Service to look at services, we can use the –Name parameter to filter by name. Not all WMI objects have a name property, so it wouldn't make sense to have a parameter to filter by this single property. The solution is to have a query language called WMI Query Language (WQL), similar to SQL, and a single parameter called –Filter that takes the WHERE clause of the WQL query in order to filter the objects.

WQL syntax is very simple to use, and is very similar to SQL. In the WQL filter, you can use the property names of classes, constants, and operators to build the conditions you are looking for. For example, to return only the AdobeARMService instance from the Win32_Service class, you could use a filter of "Name='AdobeARMService'". Note that I have used double quotes around the filter and single quotes around the string value of the Name property. The full Get-WMIObject statement and output looks as follows:

Filters can be more complex as well. Consider the Win32_LogicalDisk class, which contains an instance for each drive on the local computer:

If we wanted to list all the drives that had less than 10GB free and didn't care about the removable, we could use a filter as follows:

 -Filter "DriveType=3 and FreeSpace< 10737418240"

Here, you can see that I have calculated the value of 10GB because WQL doesn't understand units, and also, I have used a variable to hold the filter in order to keep the line shorter.

WQL syntax is very simple to use, and is very similar to SQL. In the WQL filter, you can use the property names of classes, constants, and operators to build the conditions you are looking for. For example, to return only the AdobeARMService instance from the Win32_Service class, you could use a filter of "Name='AdobeARMService'". Note that I have used double quotes around the filter and single quotes around the string value of the Name property. The full Get-WMIObject statement and output looks as follows:

Filters can be more complex as well. Consider the Win32_LogicalDisk class, which contains an instance for each drive on the local computer:

If we wanted to list all the drives that had less than 10GB free and didn't care about the removable, we could use a filter as follows:

 -Filter "DriveType=3 and FreeSpace< 10737418240"

Here, you can see that I have calculated the value of 10GB because WQL doesn't understand units, and also, I have used a variable to hold the filter in order to keep the line shorter.

The two main CIM cmdlets that you will use are Get-CIMClass and Get-CIMInstance. Although Get-WMIObject is used to retrieve both the WMI classes (with –List) and WMI instances (without –List), these roles are carried out by separate CIM cmdlets. Using Get-CIMClass is virtually identical to using Get-WMIObject with the -List switch. We can recreate the processor example from earlier in the chapter with Get-CIMClass as follows:

Retrieving instances is done, of course, with Get-CIMInstance. Filters work exactly like they do with Get-WMIObject. Also, the objects output by these two cmdlets are the same, so working with the results will be exactly the same.

The two main CIM cmdlets that you will use are Get-CIMClass and Get-CIMInstance. Although Get-WMIObject is used to retrieve both the WMI classes (with –List) and WMI instances (without –List), these roles are carried out by separate CIM cmdlets. Using Get-CIMClass is virtually identical to using Get-WMIObject with the -List switch. We can recreate the processor example from earlier in the chapter with Get-CIMClass as follows:

Retrieving instances is done, of course, with Get-CIMInstance. Filters work exactly like they do with Get-WMIObject. Also, the objects output by these two cmdlets are the same, so working with the results will be exactly the same.

We can create an app pool using the New-WebAppPool cmdlet, which only has one interesting parameter called –Name. We're going to create an app pool called ReportPool and later configure the ReportApp web application to run in this app pool:

Switching an application to run in this pool involves a PSProvider-related cmdlet called Set-ItemProperty:

We can easily verify that the changes worked using our Get-WebAppPool function from earlier in the chapter:

We can create an app pool using the New-WebAppPool cmdlet, which only has one interesting parameter called –Name. We're going to create an app pool called ReportPool and later configure the ReportApp web application to run in this app pool:

Switching an application to run in this pool involves a PSProvider-related cmdlet called Set-ItemProperty:

We can easily verify that the changes worked using our Get-WebAppPool function from earlier in the chapter: