There are four native PowerShell cmdlets that deal specifically with formatting the output of commands:

As you are first getting used to working with PowerShell, it is easy to type a command such as get-process | format-list and appreciate the ease of getting results from PowerShell without needing to have a detailed understanding of exactly how PowerShell is displaying these results. This section takes a look at the mechanics of the formatting cmdlets and describes how to customize the output of PowerShell’s formatting cmdlets to meet your own requirements.

As we discussed in Chapter 3, “Advanced PowerShell Concepts,” the Extended Type System (ETS) enables existing .NET objects to be assigned new behaviors by PowerShell. PowerShell uses ETS to include detailed formatting information for the objects that it uses. This formatting information is stored in a series of files with a .ps1xml extension that reside in the PowerShell home directory. In PowerShell 2.0 CTP2, the PowerShell home directory is C:WINDOWSsystem32WindowsPowerShellv1.0; this value is also stored in the PowerShell variable $PSHOME. The command that follows shows a list of the .ps1xml files that are part of the current release of PowerShell 2.0 CTP2.

The function of each of these seven formatting files is described in the following:

As you continue to use PowerShell for your scripting automation tasks, you will likely run into situations where it would be really helpful to be able to add an additional property to a PSObject. For example, you might want to create a new alias property to make it easier to reference a property in an existing PSObject. There are two different ways to approach this kind of task. If you just need to add a property temporarily, you can use the Add-Member cmdlet to add an additional property to an existing PSObject. The sequence of commands that follows shows how to add a NoteProperty System.String property called Status with a value of done to the type name System.IO.DirectoryInfo:

The limitation of adding properties to PSObjects interactively is that the properties persist only for the duration of your PowerShell session. After you close PowerShell, any custom properties that you have added are destroyed and need to be manually recreated in subsequent sessions if you want to use the properties again. If you find that you are making regular use of custom properties and would like to have these properties automatically loaded every time PowerShell is launched, the best solution is to create a custom .ps1xml file that can be loaded as part of your PowerShell profile. The steps that follow describe how to create your own custom .ps1xml file and add it to your Windows PowerShell console.

To create a new .ps1xml file, you can begin with a blank template similar to the one shown in the following. You should save this file in your PowerShell user profile directory with the name Types.Custom.ps1xml. To obtain the path for your PowerShell user profile, you can enter the command $profile at any PowerShell prompt. The value that is returned is similar to C:Documents and Settings<username>My DocumentsWindowsPowerShellMicrosoft.PowerShell_profile.ps1. Thus, this file should be saved as C:Documents and Settings<username>My DocumentsWindowsPowerShellTypes.Custom.ps1xml.

The previous example is a valid .ps1xml file, but it contains no data. To configure PowerShell to load this Types.Custom.ps1xml file when PowerShell starts, you can add the following lines to your PowerShell profile:

At this point, you have configured PowerShell to load a custom .ps1xml file named Types.Custom.ps1xml for your user profile when PowerShell is launched. The next step is to add some customizations to Types.Custom.ps1xml. The example that follows demonstrates adding an AliasProperty named BytesFree to the System.IO.DriveInfo PSObject, which references the existing property AvailableFreeSpace:

After you have saved the Types.Custom.ps1xml file in your PowerShell user profile directory as described previously, exit PowerShell and restart it to allow the new custom types file to be included. The example that follows shows the output of [System.IO.DriveInfo]::getdrives() pipelined to Format-List (aliased here as fl) with the properties Name, DriveType, VolumeLabel, and BytesFree. Note that PowerShell now accepts BytesFree as a valid property for System.IO.DriveInfo and returns the value for AvailableFreeSpace, even though the BytesFree label is displayed by Format-List.

Although the example shown is a relatively straightforward demonstration of adding an alias for an existing PSObject property, it is possible to perform much more detailed customizations in a .ps1xml file, such as including script blocks to assign a scripted action to a PSObject property. The following abbreviated example comes from PowerShell’s default types.ps1xml file and illustrates how the DateTime property of the System. DateTime type is populated using a series of scripted commands to parse the input and return a value:

One way to access PowerShell drives and their data is with the Set-Location cmdlet. This cmdlet, shown in the following example, changes the working location to another specified location that can be a directory, subdirectory, location stack, or Registry location:

Next, use the Get-ChildItem cmdlet to list the subkeys under the Windows key:

Note that with a Registry drive, the Get-ChildItem cmdlet lists only the subkeys under a key, not the actual Registry values. This is because Registry values are treated as properties for a key rather than a valid item. To retrieve these values from the Registry, you use the Get-ItemProperty cmdlet, as shown in this example:

As with the Get-Process command, the data returned is a collection of objects. You can modify these objects further to produce the output you want, as this example shows:

Accessing data from a FileSystem drive is just as simple. The same type of command logic is used to change the location and display the structure:

What’s different is that data is stored in an item instead of being a property of that item. To retrieve data from an item, use the Get-Content cmdlet, as shown in this example:

PowerShell drives can be created and removed, which is handy when you’re working with a location or set of locations frequently. Instead of having to change the location or use an absolute path, you can create new drives (also referred to as “mounting a drive” in PowerShell) as shortcuts to those locations. To do this, use the New-PSDrive cmdlet, shown in the following example:

To remove a drive, use the Remove-PSDrive cmdlet, as shown here:

The All Users profile is located in %windir%system32windowspowershellv1.0profile.ps1. Settings in the All Users profile are applied to all PowerShell users on the current machine. If you plan to configure PowerShell settings across the board for users on a machine, then this is the profile to use.

This profile is located in %windir%system32windowspowershellv1.0ShellID_profile.ps1. Settings in the All Users host-specific profile are applied to all users of the current shell (by default, the PowerShell Console). PowerShell supports the concept of multiple shells or hosts. For example, the PowerShell Console is a host and the one most users use exclusively.

However, other applications can call an instance of the PowerShell runtime to access and run PowerShell commands and scripts. An application that does this is called a hosting application and uses a host-specific profile to control the PowerShell configuration. The host-specific profile name is reflected by the host’s ShellID. In the PowerShell Console, the ShellID is the following:

Putting this together, the PowerShell Console’s All Users host-specific profile is named Microsoft.PowerShell_profile.ps1. For other hosts, the ShellID and All Users host-specific profile names are different. For example, the PowerShell Analyzer (www.powershellanalyzer.com) is a PowerShell host that acts as a rich graphical interface for the PowerShell environment. Its ShellID is PowerShellAnalyzer.PSA, and its All Users host-specific profile name is PowerShellAnalyzer.PSA_profile.ps1.

This profile is located in %userprofile%My DocumentsWindowsPowerShellprofile.ps1. Users who want to control their own profile settings can use the current user’s profile. Settings in this profile are applied only to the user’s current PowerShell session and don’t affect any other users.

This profile is located in %userprofile%My DocumentsWindowsPowerShellShellID_profile.ps1. Like the All Users host-specific profile, this profile type loads settings for the current shell. However, the settings are user-specific.

As the name indicates, a global scope applies to an entire PowerShell instance. Global scope data is inherited by all child scopes, so any commands, functions, or scripts that run make use of variables defined in the global scope. However, global scopes are not shared between different instances of PowerShell.

The following example shows the $Processes variable being defined as a global variable in the ListProcesses function. Because the $Processes variable is being defined globally, checking $Processes.Count after ListProcesses completes returns a count of the number of active processes at the time ListProcesses was executed.

A local scope is created dynamically each time a function, filter, or script runs. After a local scope has finished running, information in it is discarded. A local scope can read information from the global scope but can’t make changes to it.

The following example shows the locally scoped variable $Processes being defined in the ListProcesses function. After ListProcesses finishes running, the $Processes variable no longer contains any data because it was defined only in the ListProcesses function. As you can see, checking $Processes.Count after the ListProcesses function is finished produces no results.

A script scope is created whenever a script runs and is discarded when the script finishes running. To see an example of how a script scope works, create the following script and save it as ListProcesses.ps1:

After you have created the script file, run it from a PowerShell session. Your output should look similar to this example:

Notice that when the ListProcesses.ps1 script runs, information about the first process object in the $Processes variable is written to the console. However, when you try to access information in the $Processes variable from the console, an error is returned because the $Processes variable is valid only in the script scope. When the script finishes running, that scope and all its contents are discarded.

A private scope is similar to a local scope, with one key difference: Definitions in the private scope aren’t inherited by any child scopes.

The following example shows the privately scoped variable $Processes defined in the ListProcesses function. Notice that during execution of the ListProcesses function, the $Processes variable isn’t available to the child scope represented by the script block enclosed by { and } in lines 6–9.

This example works because it uses the ‘&' call operator. With this call operator, you can execute fragments of script code in an isolated local scope. This technique is helpful for isolating a script block and its variables from a parent scope or, as in this example, isolating a privately scoped variable from a script block.