Windows

While many of your scripts will be designed to work in isolation, you will often find it helpful to give your script information about its execution environment: its name, current working directory, environment variables, common system paths, and more.

PowerShell offers several ways to get at this information—from its cmdlets, to builtin variables, to features that it offers from the .NET Framework.

When you write scripts that heavily interact with the user, you may sometimes feel that your script could benefit from better performance.

Problem

You want to access detailed debugging or diagnostic information for the execution of a script or command.

Solution

To trace a script as it executes, use the Trace parameter of the SetPsDebug cmdlet.

To view detailed trace output for the PowerShell engine and its cmdlets, use the TraceCommand cmdlet.

Discussion

Problem

You want to diagnose failures or unexpected behavior in a script interactively.

Solution

To generate debugging statements from your script, Use the WriteDebug cmdlet. If you want to step through a region carefully, surround it with SetPsDebug –Step calls. To explore the environment at a specific point of execution, add a line that calls $host.EnterNestedPrompt().

Discussion

Problem

You want your script to notify its caller of a warning, error, or terminating error.

############################################################################## ## ## GetWarningsAndErrors.ps1 ## ## Demonstrates the functionality of the WriteWarning, WriteError, and throw ## statements ## ##############################################################################

WriteWarning "Warning: About to generate an error" WriteError "Error: You are running this script" throw "Could not complete operation."

Solution

Problem

You want to handle warnings, errors, and terminating errors generated by scripts or other tools that you call.

Solution

To control how your script responds to warning messages, set the $warningPreference variable. In this example, to ignore them: $warningPreference = "SilentlyContinue"

To control how your script responds to nonterminating errors, set the $errorActionPreference variable. In this example, to ignore them:

Problem

You want to view the errors generated in the current session.

Solution

To access the list of errors generated so far, use the $error variable, as shown by Example 131.

Example 131. Viewing errors contained in the $error variable

PS >1/0 Attempted to divide by zero. At line:1 char:3

+ 1/0 <<<< PS >$error[0] | FormatList Force

ErrorRecord
: Attempted to divide by zero.

StackTrace
:
at System.Management.Automation.Parser.ExpressionNode.A

(...)

What if it doesn’t all go according to plan? This is the core question behind error management in any system and plays a large part in writing PowerShell scripts as well.

While it is a core concern in many systems, PowerShell’s support for error management provides several unique features designed to make your job easier: the primary benefit being a distinction between terminating and nonterminating errors.

While the techniques provided in the rest of this chapter are usually all you need, it is sometimes helpful to provide a graphical user interface to interact with the user.

Since PowerShell fully supports traditional executables, simple programs can usually fill this need. If creating a simple program in an environment such as Visual Studio is inconvenient, you can often use PowerShell to create these applications directly.

Example 129 demonstrates the techniques you can use to develop a Windows Forms application using PowerShell scripting alone.

Problem

You want to interact with features in the user interface of the hosting application, but PowerShell doesn’t directly provide cmdlets for them.

Solution

To access features of the host’s user interface, use the $host.UI.RawUI variable: $host.UI.RawUI.WindowTitle = (GetLocation)

Discussion

PowerShell itself consists of two main components. The first is an engine that interprets commands, executes pipelines, and performs other similar actions. The second is the hosting application—the way that users interact with the PowerShell engine.