Variables

Like many scripting environments, PowerShell supports the creating and use of variables. Think of a variable as a container that has a name and can hold values. For example, the following command creates a new variable named $var and assigns it the numeric value 100.

 PS C:\>$var = 100 

Keep in mind that variable names always begin with $ in PowerShell.

You can declare variables right at the PowerShell prompt; you don't need to be running a script. For example:

 PS C:\Documents and Settings> $var = "C:\" PS C:\Documents and Settings> set-location $var PS C:\> 

In the first line of this example, the variable $var is declared and set to contain the string value "C:\". Notice the double quotation marks around the value that mark it as a string, or a series of characters, rather than a number. The second line executes the Set-Location cmdlet, passing the contents of $var. As you can see from the prompt on the third line, the location was successfully changed to C:\. It's important to note that, when variables are used, it's the contents of the variable that are passed along, not the variable name. In other words, we weren't trying to set the location to a location named "$var". Instead, we set the location to whatever was contained within the variable $var.

Variables can also contain the output of cmdlets. For example, the following runs the Get-Process cmdlet and put its entire output into the variable $a:

 PS C:\>$a = get-process 

Did you notice that $a was never declared, as some scripting languages require or allow you to do? PowerShell doesn't need variables to be declared in advance, which means you can make up and use new variables as you go. In fact, unlike some languages, PowerShell is designed so, as a general rule, variables aren't declared in advance.

Variable Names and Intrinsic Variables

Variable names can contain any character. However, as shown below, the variable must be enclosed in curly braces if it doesn't start with a letter.

 $var = 4 $var2 = 3 ${@@123} = 2 

It can be a bit confusing to use variable names like @@123, so we recommend sticking with textual, meaningful names. Interestingly, a variable name can be a path such as:

 PS C:\>${C:\File.txt} = "Hello!" 

This variable name writes "Hello!" to a text file named C:\File.txt. Remember that every resource PowerShell connects to can be presented with a file-like path. For example, the path HKLM\SOFTWARE goes to the registry. This can be a powerful technique for quickly changing values in various resources.

PowerShell provides a number of built-in variables including automatic variables and policy variables that are listed in the PowerShell documentation. These built-in variables provide information about the current environment, currently-executing host, and so forth. Keep in mind that you shouldn't name your own variables any of the names used by these built-in variables.

Variables are Objects

It's important to understand that PowerShell variables are objects. This is unlike languages like VBScript, where variables are simply containers for values. In the case of PowerShell, a variable does contain a value, but since it's an object, it also has a number of intrinsic capabilities. For example:

 PS C:\>$var = "Hello, World" 

This variable assigns the value "Hello, World" to the variable $var. $var now contains that variable, but $var also has a number of capabilities as an object (something we'll touch in more in Chapters 4 and 5). One of the capabilities is the SubString() method, which is listed below.

 PS C:\>Write-Host $var.SubString(2,2) 

This calls the Write-Host cmdlet, which outputs text to the console. It asks that the $var object execute its SubString() method, which starts at the third character position (numbering begins with 0, so 2 is the third character) and takes 2 characters. This will output "ll" to the console. Similarly, the following example outputs the number 12, because that's how long the contents of $var are: 12 characters

 PS C:\>Write-Host $var.Length 

Note that PowerShell doesn't visually differentiate between variables that contain strings and those that contain numbers:

 $var = 5 $var = "Hello" 

Both are perfectly legal. However, PowerShell can tell the difference. Variables containing string values are referred to as string objects, and they come with a rich variety of methods and properties such as SubString() and Length. For example:

 PS C:\> $var = 3 PS C:\> write-host $var.length PS C:\> $var = "Hello" PS C:\> write-host $var.length 5 

First, $var is given the numeric value 3. When asked to output the length, PowerShell cannot because 3 isn't a string, and so $var isn't a string object. However, when the contents of $var are replaced by the string "Hello," $var becomes a string object and has a valid Length property as shown in the output.

So, you're probably wondering where we found out about Length, SubString, and so forth. The short answer is - Chapter 5, where we'll cover variables in more depth. However, a longer answer is that PowerShell can sort of tell you. Type $a = "hello" into PowerShell and hit Enter. Then type $a. (be sure to include a period after the letter "a") and hit Tab. PowerShell will start to list each member of the String object of which your variable $a is an instance. A new member will be listed each time you hit Tab. Eventually, you'll come to SubString. This use of Tab is a type of text-based substitute for the code completion features (which go by brand names such as IntelliSense and PrimalSense) in graphical development environments.

String Variables and Embedding

String variables treat embedded variables in an interesting fashion. For example, consider the following where $var2 is embedded in a literal string:

 PS C:\> $var = "Hello" PS C:\> $var2 = "$var, World!" PS C:\> write-host $var2 Hello, World! 

In this example, the value "Hello" was assigned to $var. The value "$var, World!" was assigned to $var2. When passed to Write-Host, $var was expanded, which means its contents were displayed. This occurs because $var2 was assigned using double quotation marks. Now, consider a similar example:

 PS C:\> $var = "Hello" PS C:\> $var2 = '$var, World!' PS C:\> write-host $var2 $var, World! 

Notice the difference? This time, the value passed into $var2 was contained in single quotation marks instead of double, which prevented $var from being expanded. So the literal value "$var, World!" was stored in $var2, as evidence by the Write-Host output. $var2 is still considered a string object, and either single quotes or double quotes can be used to contain strings.

Strings assigned with double quotation marks can also contain embedded expressions. For example:

 PS C:\> $var = "2+2 is $(2+2)" PS C:\> write-host $var 2+2 is 4 

Anything with a $ is considered either a variable or expression and is evaluated accordingly. In this case, the expression (2+2) was recognized as a mathematical expression, and it was evaluated for its result. Here's one last useful example:

 PS C:\> $var = "Hello" PS C:\> $var2 = "$var, World!" PS C:\> $var = "Goodbye" PS C:\> write-host $var2 Hello, World! 

Notice that the output of Write-Host is "Hello, World!" and not "Goodbye, World!" as you might expect. This occurred because $var was expanded when it was assigned into $var2. In other words, $var2 contains the static string, "Hello, World!" because $var contained "Hello" at the time the value was assigned to $var2. Later changes to $var do not effect the existing contents of $var2.

Parsing Mode

All of this quotation stuff can get confusing because it works somewhat differently at the command line when you're typing text into PowerShell. For example:

 PS C:\> write-host 2+2 2+2 PS C:\> 

Why didn't it display 4? Because at the command line everything is considered a string unless it appears in parentheses or starts with $, which means it's a variable. So, this works differently:

 PS C:\> write-host (2+2) 4 PS C:\> 

Why the difference? At the command line, PowerShell treats everything as a string, which means you don't have to put quotation marks around everything. That allows you to run:

 PS C:\>Set-Location C:\ 

Rather than having to type:

 PS C:\>Set-Location "C:\" 

This would be cumbersome and unintuitive, since it's not the way past Windows shells have worked.

This is all called the shell parsing mode, whether the shell treats things as strings by default or not. The rules are pretty simple:

• If the first character is a number, a variable ($), or a quoted string, then the shell works in expression mode, in which all strings must be quoted.

• If the first character is a letter, ampersand (&), or a dot followed by a space or a letter, then the shell works in command mode, which is where everything is assumed to be a string unless it's a variable or is in parentheses, as we've demonstrated.