Chapter Three:  
Variables

Variables

PowerShell variables can be used to store values of all types ("About_Variables - Powershell", 2019). Most importantly, command results, command items, and expression items can all be stored in variables. The specific command and expression items include settings, values, paths, and names. A PowerShell variable is a memory unit that stores values. Variables in PowerShell are denoted by a text string with a preceding dollar sign, denoted as ($). Examples are $my_var, $a, or $process. A variable name can include special characters and spaces. Additionally, variable names are not case-sensitive. Variable names with spaces and special characters, however, are discouraged as they are difficult to script with and their usage can interfere with scripting expression.

PowerShell variables fall into three general categories:

●        User-created variables: These are variables the user creates and maintains. These variables, by default, only exist as long as the console window remains open. Upon exiting the console window, these variables are erased. A user-created variable can be saved by adding it to your profile. These variables can also be created in local scripts having a global scope. PowerShell scopes will be considered later in this chapter.

●        Automatic variables: These variables are created and maintained by PowerShell. They store the PowerShell state. Their values cannot be changed by users. The variables are changed by PowerShell to preserve their accuracy. An example is the variable $PSHOME, which stores the Powershell installation directory path.

●        Preference variables: These are variables that store PowerShell user preferences. PowerShell initially creates them and populates them using default values. Users are then able to alter these values. An example is the variable $MaximumHistoryCount, which defines the maximum entry count in the current session history.

Variable Management

A new PowerShell variable is created by assigning the variable a value by using a statement. It is not necessary to declare the variable beforehand. Variables have a default value of $null. The Get-Variable cmdlet lists all variables in the current session, displayed without the leading dollar symbol ($). To illustrate, these two statements create new variables $NewVariable and $User:

>$NewVariable = 10,20,30

>$User = "User"

The two statements below respectively store the results of the Get-Process command and the formatted output of the Get-Date command:

>$Processes = Get-Process

>$Today = (Get-Date).DateTime

There are two ways to display variable contents. The first method is to type the name of the variable preceded by a leading dollar sign ($). The following two statements show the contents of NewVariable and Today:

>$NewVariable

10

20

30

>$Today

Tuesday, December 12, 05:17:30

The second method is to use the Get-Variable cmdlet with the Name parameter:

>Get-Variable –Name NewVariable

Name                       ​ Value

----                       ​ -----

NewVariable                ​ {10, 20, 30}

>Get-Variable $Today

Tuesday, December 12, 05:17:30

The value stored in a variable can be changed using another assignment statement. The following statement sequence displays the value of $NewVariable, changes the stored value, and displays $NewVariable again with a new value:

>$NewVariable= 10,20,30

>$NewVariable

10

20

30

>$NewVariable = cat, dog, mouse

>$NewVariable

cat

dog

mouse

The cmdlet Clear-Variable can be used to remove the value stored in a variable. The alternative is to assign the $null value to the variable. The following statements illustrate both these approaches:

>Clear-Variable -Name NewVariable

>$NewVariable

>

>$NewVariable = cat, dog, mouse

>$NewVariable

cat

dog

mouse

>$NewVariable = $null

>$NewVariable

>

The Remove-Variable and Remove-Item cmdlets can be used to delete a variable:

>Remove-Variable -Name NewVariale

>Remove-Item -path Variable:\NewVariable

The second command uses the Variable: drive notation to delete the variable. Variable: drive will be considered later in this chapter.

Types of Variables

PowerShell variables can store an object of any type. The object types can be simple types such as strings, integers, hash tables, and arrays, or they can be more complex, such as objects denoting services, computers, and event logs. Variables in PowerShell are freely typed, meaning that they are not limited to having an explicit object type. One variable can contain an array or a set of un-like object types simultaneously. The variable data type depends on the value .NET types assigned to the variable. The Get-Member cmdlet is used to display the object type of a variable. These concepts are illustrated by the following command sequence:

>$a = 12 # System.Int32

> $a

12

>$a = "Word" # System.String

>$a

Word

>[datetime] $dates = "09/12/19"  # This converts the string to type DateTime object.

>$dates

12 September 2019 12:00:00 AM

>$a = 12, "word"  #array of System.Int32, System.String

>$a

12

word

>$a = Get-ChildItem C:\Windows # DirectoryInfo and Field Info types

Variable attribute type and casting notation can be used to restrict the object types that can be stored in a variable. This method restricts the object type stored to either an explicitly specified type or a type that PowerShell can convert to the specified type. If the type conversion is not possible, then the statement for the variable assignment fails.

To use this method, denote the specific cast type enclosed in square brackets [] to the left of the variable name in the variable assignment statement (which will include the variable reference symbol ($) on the left or subject side of the statement) with no intervening spaces.

The following command sequence illustration creates three variables: a $numeric variable with a specified type of integer, a "text" variable of specified type string, and a $dates variable of specified type DateTime object.

In case of the $numeric variable:

[int]$numeric = 2

$number = "18"  # In this case the string is converted to an integer.

$number = "Hi"

This will generate the following output:

> [int]$numeric = 2

> $numeric = "18"  # In this case the string is converted to an integer.

> $numeric = "Hi"

Cannot convert value "Hi" to type "System.Int32". Error: "Input string was not in a correct format."

At line:1 char:1

+ $number = "Hi"

+ ~~~~~~~~~~~~~~

​ + CategoryInfo      ​ : MetadataError: (:) [], ArgumentTransformationMetadataException

​ + FullyQualifiedErrorId : RuntimeException

In the case of the $words variable:

>[string]$text = "Hello PowerShell"

>$text = 4   ​ # The integer is converted to a string.

>$text += 20 ​ # The plus (+) sign concatenates the strings.

>$text

420

In the case of the $dates variable:

>[datetime] $dates = "12/09/19"  # The string is converted to a DateTime object, according to culture setting

> $dates

Monday, December 9, 2019 12:00:00 AM

Variables in Expressions and Commands

Expressions and commands share the same syntax for using variables as previously discussed. The variable name (string) with a leading variable reference dollar ($) symbol is typed in the expression or command. The value that will be used in the expression for the variable depends on how the name of the variable appears in the expression or command. If $variable_name has no other symbols or appears enclosed with a double quotation symbol (“), then the value stored in the variable will be used when the expression or command is evaluated. If $variable_name appears within a single quotation symbol (‘), then variable_name will be used when the expression or command is evaluated (note the $ is removed).

The following illustration considers the $PROFILE automatic variable, which stores the path to the file of the user profile, on the console.

>$PROFILE

C:\Users\<User>\Documents\PowerShell\Microsoft.PowerShell_profile.ps1

PS C:\>

In this illustration, PowerShell obtains the value of the $variable, which is an integer value of 1, converts it to text, and concatenates it with 2, where the $variable name is enclosed in double quotation symbol. In the second expression, where the variable name $variable is enclosed in a single quotation symbol, the variable name is converted to text and concatenated with 2.

>[int] $variable = 1

>"$variable" + 2

12

>'$variable' + 2

$variable2

Variable Names with Special Characters

Variable names can include alphanumeric and special characters. The length of the name of the variable is only restricted by the memory available. The recommended practice is for variable names to only include alphanumeric characters as well as the underscore symbol (_). Variable names with spaces and special characters other than the underscore ought to be steered away from because they are hard to use.

Variable names that are designated alphanumeric may contain the following characters:

●         Unicode characters contained in categories: Ll, Lm, Ll, Lu, Lo or Nd.

●         Underscore symbol (_).

●         Question mark (?).

This list contains descriptions for the Unicode categories:

●         Ll: LowercaseLetter

●         Lm: ModifierLetter

●         Ll: LowercaseLetter

●         Lu: UppercaseLetter

●         Lo: OtherLetter

●         Nd: DecimalDigitNumber

The approach for creating or displaying a name for a variable which includes a special character or a space is to enclose the name with curly brace symbols {}. The curly brace symbols are a directive to PowerShell to interpret all characters in the variable name as literals.

Variable names designated as special character may contain any Unicode character other than the following:

1. Right curly brace } character "U+007D".
2. Backtick (`) character "U+0060". The backtick symbol is used by Unicode characters as an escape so they can be considered literals.

PowerShell has a set of reserved variables containing alphanumeric as well as special characters. These variables are variables such as $?,$$,$_ and $^. These are part of the PowerShell set of automatic variables. The following examples illustrate these naming conventions. The curly braces are required because of the (-) special character.

>${list-items} = "a", "b", "c", "d"

>${list-items}

a

b

c

d

>${number-items} = 1,2,3,4,5

>${number-items}

1

2

3

4

5

>${date-items} = "01/09/2019","02/09/2019","03/09/2019"

>${date-items}

01/09/2019

02/09/2019

03/09/2019

In this example, a variable called ProgramFiles(x86) with an environmental scope is created and used as an input to the Get-ChildItem cmdlet:

>Get-ChildItem ${env:ProgramFiles(x86)}

The curly braces need to be used to escape the ( and ) characters. We will discuss the meaning of the env: below when we briefly talk about variable scopes. In order to give a variable a name that includes curly braces, enclose the variable name in braces and use the backtick character to escape the braces in the variable name. To illustrate, the following creates a variable with name array{1} and displays the output:

>${array`{1`}} = "This variable name uses braces and backticks."

>${array`{1`}}

This variable name uses braces and backticks.

Variable Scope

When a variable is created in a particular scope, then it is by default only available in that scope. To illustrate, a variable created within a function only becomes available within that function. A variable created within a script only becomes available within that script. If, however, a script is dot-sourced, then that variable is available in the local or current scope. The default variable scope can be changed using an optional scope modifier. The following variable assignment creates a $Servers variable:

>$Global:Servers= "Server01","Server02","Server03"

>$Global:Servers

Server01

Server02

Server03

This assignment statement is such that the scope of the variable will be global even when created within a function or script.

Access to PowerShell aliases, functions, variables and drives is protected. PowerShell achieves this by limiting the circumstances under which a user can read and modify them. This is facilitated by PowerShell scoping rules. Scoping rules ensure that items are not inadvertently changed when it is not ideal to do so.

The basic scope rules are:

●        Scopes are able to nest. Any outer scope is considered the parent scope. Any scopes nested in that parent scope are its child scopes.

●        An item created in a scope becomes visible in that scope and any of its child scopes, unless it is explicitly made private. Aliases, variables, functions, or PowerShell drives can be placed in one or multiple scopes.  

●        An item created within a specific scope can only be modified in that scope, unless a different scope is specified for that purpose.

If an item is created within a scope and has the same name as an item from another scope, then the first item to be created can be hidden under the more recent item, but will not be overridden or modified.

Types of Scopes

PowerShell has the following scopes:

●        Global: This is the scope during PowerShell start-up. Variables that are in PowerShell at  start-up were created within the global scope. These include preference and automatic variables. This applies analogously to functions. PowerShell user profile aliases, variables, and functions at PowerShell start-up were also created in this scope.

●         Local: A current scope. This scope can be global or another scope.

●        Script: This is the scope which is generated when a script runs. This is the scope where only the script commands run. This scope is also the current or local scope for the script commands.

It is important to highlight that private is a visibility option for an item rather than a scope. The private option of an item determines whether items outside of its scope can view it.

Parent and Child Scopes

Another scope can be created either by executing a function or script, starting a new session, or a new PowerShell instance. The newly created scope is a nested child scope of the original parent scope. Thus, in PowerShell, scopes are nested child scopes of the parent global scope. It is possible to create multiple scopes and multiple recursive scopes. Items within a parent scope can be used by its child scope unless explicitly made private. The items created and modified within the nested child scope, by default, will not impact the original parent scope. Items in the child scope can affect objects in the parent scope if their scope is specifically specified to be the parent scope when they are created.

Inheritance

A nested child scope will not inherit items such as aliases, variables, and functions from its parent scope. An item of the original parent scope is visible to the nested child scope, unless it is private. These items can be modified by the nested child scope by specifically referencing the original parent scope, however, they are not in the nested child scope. A nested child scope does have a collection of items when it is created. These usually include all aliases with the Option property set to AllScope. The Option property will be discussed later in this chapter under Scope modifiers. This includes all variables with the Option property set to AllScope. Items in a specific scope can be found using the Get-Alias or Get-Variable cmdlets invoked with the target scope as the value for the Scope parameter. To illustrate, variables in the local scope can all be displayed with the command:

>Get-Variable -Scope local

And those in the global scope with the following command:

>Get-Variable -Scope global

Scope Modifiers

A function name or alias may have an optional scope modifier. This can be selected to be one of:

●         global: This designates the scope where the name should exist should be Global.

●        local: This designates the scope where the name should exist should be Local. The current and local scopes are the same.

●        private: This designates the name to be Private and visible only to the local scope.

●        script: This designates the scope where the name should exist should be Script. The Script scope is the nearest

●         parent of the scope of the script file or Global otherwise.

●        using: This allows variables of another scope to be accessed when running scripts using cmdlets like Invoke-Command and Start-Job.

●        <variable-namespace>: A scope modifier that is created by a PSDrive provider. The following are examples of the <variable : namespace> syntax:

The script scope is the default script file scope. The local scope is the default aliases scope and default functions scope, even when defined by a script.

Using Scope Modifiers

A way to designate the scope when creating a new alias, variable, or function is by using an optional scope modifier.  In the case of variables, the syntax is as follows:

>$[<scope-modifier>:]<name> = <value>

In the case of functions, the syntax is as follows:

>function [<scope-modifier>:]<name> {<function-body>}

This command is an assignment expression to create or modify a variable $a in the local or current scope:

>$a = "a"

To create the variable $a such that it exists in a global scope, use a scope modifier set to global, as follows:

>$global:a = "a"

Similarly, to create the variable $a such that it exists in the script scope, use a scope modifier set to script, as follows:

>$script:a = "a"

The optional scope modifier can be used with functions. This function definition will create a function that exists in the global scope:

>function global:Hello {

Write-Host "Hello, World"

}

Optional scope modifiers can also be used when denoting a variable within another scope. The following denotes the $variable variable, initially in the current scope and subsequently within the parent global scope:

>$variable

>$global:variable

The Using: Scope Modifier

The Using: scope modifier is a special modifier used to identify a local variable in a remote command. When a modifier is not used, PowerShell requires that variables that are part of remote commands be part of the remote session variable definition. This scope modifier was introduced in Windows PowerShell 3.0.

AllScope Option

An item with an Option property that is AllScope becomes visible to and part of the nested child scope. Modifications to that item in any of the scopes immediately affects all scopes where it is defined.

Managing Scope

A variety of cmdlets also have a parameter that can be used for managing scope. This parameter is called the Scope parameter. This parameter used in conjunction with the cmdlets provides a means to either get, change or create items within a specified scope. This command finds all cmdlet in the session with the Scope parameter:

>Get-Help * -Parameter scope

Variables which are visible within a specific scope can be found using the Get-Variable cmdlet and its Scope parameter. The variables that will be visible include parent scope variables, current scope variables, and global variables. This command displays variables which are visible to the current scope:

>Get-Variable -Scope local

Variables can be created in a scope specific manner using the optional scope modifier or the Set-Variable cmdlet Scope parameter. This command creates a variable with a scope that is global:

>New-Variable -Scope global -Name numeric -Value 1

The New-Alias, Get-Alias or Set-Alias cmdlets have a Scope parameter that can be used for specifying the scope. This command will create an alias whose scope is global:

>New-Alias -Scope global -Name command -Value cmd.exe

It is possible to still display functions within a scope but not use the Scope parameter of a cmdlet. The approach is to first select the target scope and then invoke the cmdlet Get-Item within the target scope.

It is important to note that cmdlets whose parameters include a Scope parameter allow for scopes to be referred to by number. The number labels the relative location of a scope to a different one. Scope 0 is the local or current scope. Scope 1 is the direct parent scope. Scope 2 is the direct parent of Scope 1, and the like. Numbered scopes have great utility in a setting where multiple recursive scopes have been created. 

Using Dot Source Notation with Scope

Functions and scripts stick to scope rules. They are created in a specific scope and have an impact only on that scope with the exception being if a parameter of a cmdlet or an optional scope modifier is used to alter the scope. Dot sourcing can also add a function or script to the local scope. When the script executes in the local scope, any aliases, variables and functions created by the script become available to the local scope. A function can be added to the local scope by typing a dot symbol (.) followed by a space preceding the function path location and name within the call to the function. To illustrate, a Sample.ps1 script located in the path C:\Scripts can be executed within its script scope (which is the default scope for a script) with this command:

>C:\Scripts\Sample.ps1

In order to run the Sample.ps1 scripts in the C:\Scripts folder then use any of the following two commands:

>./Sample.ps1

>.\Sample.ps1

This command runs a Sample.ps1 script located in the path C:\Scripts within the current scope (using dot sourcing):

>. C:\Scripts\Sample.ps1

When the call operator, designated with the symbol &, is used to execute a script or function, then it is not included in the local scope. This command executes the Sample.ps1 script in the located in the path C:\Scripts by calling the script via &:

>& C:\Scripts\Sample.ps1

Any variables, functions, or aliases created while executing the Sample.ps1 file will not be available within the local scope.

Restricting Without Scope

Some PowerShell concepts interact with or are comparable to scope. These can be easily mistaken to have the behavior of or similar to scope.  Nested prompts, modules, and sessions are not session-nested child scopes of the parent global scope but autonomous environments.

●     Sessions

A session can be described as a self-contained environment on which PowerShell operates. When a remote computer-based session is created, PowerShell establishes a persistent connection with that computer. The resulting session is based on this connection, which facilitates the running of several associated commands. The session, being a self-contained environment, has a separate individual scope, but the session is not itself a nested child scope within the session that created it. The session begins with an individual global scope. The original global scope is not dependent on the new global scope of the remote session. Child scopes can be created in the remote session. To illustrate, a script can be executed in the remote session.

●     Modules

Modules are used to deliver and share PowerShell tools. A module can be characterized as a component within which aliases, variables, functions, scripts, cmdlets, and other useful items can be contained. Unless specifically stated, module items cannot be accessed externally of the module. A module can, therefore, be added to a session and its public items used without concerns that they will override the functions, scripts, cmdlets, and other items within the session.

Modules are, by default, not loaded into the local scope but rather the highest level of the current PowerShell session’s state. This state is either the module session or global session state. When a session is supplemented with a module, this action does not modify the scope of the session. When your scope is global, then module loading will be at the global state. The placement of any exports will be into the tables at the global level. If a module, say module_2, is loaded from within another module, say module_1, then module_2 will be loaded under the state of the session of module_1, rather than the state of the global session. The placement of any exports from module_2 will be into the state of the session of module_1.

In the case where the Import-Module cmdlet has a local Scope parameter, exports will be placed into the object of the local scope instead of at the highest level. If the Import-Module cmdlet with a global value is used within a module to load a different module, then the imported module is loaded with a global state rather than that of the module from which it was imported. The exports of the imported module will analogously load into the state of the global session as well. This feature was designed for a module that could manage other modules. This is used by the PowerShell WindowsCompatibity module to facilitate the loading into the state of the global session loading of proxy modules.

●     Nested Prompts

When the user enters a prompt that is nested, this prompt is part of the PowerShell environment in the current scope. Similarly, during script debugging, scripts have a default scope. When a script breakpoint is reached, then the user will go into the script scope. In both cases, the nested prompt is a self-contained environment with no individual scope.

●     Private Option

To illustrate, suppose a user first creates a variable with a default scope that is global and additionally has an Option property with a value that is private. If the user proceeds to run a Get-Variable command in a script, then this command will not display the variable. The optional global scope modifier will not display this variable in this setting. The private option of a variable can be set by invoking either the Set-Variable or New-Variable cmdlets with an option parameter. Similarly, the private option of an alias can be set by invoking either the Set-Alias or New-Alias cmdlets with an option parameter.

●     Visibility

The Visibility property operates on containers in a similar manner to how the Option property operates on scopes. The Visibility property assumes a value of either Private or Public. Items with a private value can only be changed and viewed by items inside the container that created them. They cannot be changed or viewed when their container is imported or added.

Visibility operates in a different manner within a scope because it is designed for containers. If an item has a private Visibility value within a global scope, then it cannot be changed or viewed in all scopes. If the user tries to change or view the value stored in a variable that has a private Visibility value, this will result in a PowerShell error message.

Let us illustrate these concepts on scope with some examples.

Example: Change a Variable Value Only in a Script

In this illustration, we run a script command to change the stored value inside the variable $ConfirmPrecedence. Initially, display the value stored in the variable $ConformPreference in the current scope using this command:

>  $ConfirmPreference

This will yield:

High

Compile the following commands into a script file called Scope.ps1:

$ConfirmPreference = "Low"

"The value of `$ConfirmPreference is $ConfirmPreference."

Execute the script. The script execution alters the stored value in the variable $ConfirmPreference and conveys it within the scope. The resulting output should be similar to the following:

The value of $ConfirmPreference is Low.

The last step is to compare this with the current stored value of the variable $ConfirmPreference within the local scope:

>$ConfirmPreference

This should generate the following output:

High

This illustration demonstrates that modifications to the stored variable value within the scope that is script will have no impact on the stored value of a variable in the global parent scope.

Example: View a Variable Value in Different Scopes

The optional scope modifiers can be used to display the stored variable value in the current scope as well as the parent scope.

Initially, we store a value inside a variable called $test within the scope that is global:

>$test = "Global"

Then, create a script called Sample.ps1. Inside the script place an assignment statement that stores a value in a variable called $test and use an optional scope modifier to state both $test variable versions.

$test = "Local"

"The local value of `$test is $test."

"The global value of `$test is $global:test."

Executing the Sample.ps1 script will generate output that is similar to the following:

The local value of $test is Local.

The global value of $test is Global.

After the script executes, the $test variable value definition in the global scope applies in the local session:

> $test

It will generate the following output:

Global

Example: Change the Value of a Variable in a Parent Scope

A stored variable value can be modified and displayed, unless it is protected by either using a private value for the Option property or a different method, in its parent scope. Initially, assign a stored value to a variable called $test within the scope that is global:

>$test="Global"

Then, create a script file called Sample.ps1. Inside the script, place a variable assignment that stores in a variable called $test and use an optional scope modifier to state both $test variable versions:

$global:test = "Local"

"The global value of `$test is $global:test."

After the script executes, the $test variable value in the global scope is modified:

>$test

This should generate the following output:

Local

Example: Creating a Private Variable

A variable is said to be private if it has a private value for the Option property. Private variables can only be modified or viewed within the scope where they are created, even though they are inherited within the nested child scope. This command assigns a value to a $ptest variable, which is a variable that is private, within the current scope:

>New-Variable -Name ptest -Value 1 -Option private

The $ptest value can be modified and viewed in the current scope:

>$ptest

>$ptest=2

>$ptest

This will yield the following output:

>$test

1

>$ptest = 2

>$ptest

2

Then, create a script called Sample.ps1. Place these commands in the script to view the $ptest value:

"The value of `$Ptest is $Ptest."

"The value of `$Ptest is $global:Ptest."

The resulting output has no value for $ptest because the variable cannot be viewed from the scope of the script:

"The value of $Ptest is ."

"The value of $Ptest is ."

Saving Variables

Variables that are created in a session can only be accessed in that session. They are only part of that session and are removed once the session is closed. Variables can be made available to other PowerShell sessions by adding them to your profile. To illustrate, add this command into your profile to modify the $VerbosePreference variable value in other sessions:

$VerbosePreference = "Continue"

To add a command to your profile, modify the file stored in the path $PROFILE using a text editor.

Variable: drive

The Variable provider exposes the drive designated Variable:. This drive behaves and appears similar to the drive of a file system, but instead contains information about your session variables, such as their values. To change your location to be drive designated Variable:, use this command:

>Set-Location Variable:

The variables and items in the drive designated Variable: can be displayed using the Get-ChildItem or Get-Item cmdlets.

>Get-ChildItem Variable:

A value for a specific variable can be obtained by specifying the drive name and variable name using the notation for a file system. To illustrate, this command displays the value of the $PSCulture variable, which is a PowerShell automatic variable:

>Get-Item Variable:\PSCulture

This will yield the following according to your PowerShell culture setting:

Name                       ​ Value

----                        ​ -----

PSCulture                  ​ en-US

To display the help file for the drive designated Variable: and its associated provider use this command:

>Get-Help Variable:

Variable Syntax with Provider Paths

The PowerShell variable syntax dollar symbol ($) can also be used with provider paths. The provider path should be prefixed with the dollar symbol ($) to access the provider contents. The provider should, however, implement the interface designated IContentCmdletProvider. The built-in providers supporting this notation are shown in Table 3.

Variable Cmdlets

PowerShell has a set of cmdlets that are designed to manage variables. In order to list these cmdlets, type:

>Get-Command -Noun Variable

It will generate the following list:

CommandType	Name	ModuleName
-----------	----	----------
Cmdlet	Clear-Variable	Microsoft.PowerShell.Utility
Cmdlet	Get-Variable	Microsoft.PowerShell.Utility
Cmdlet	New-Variable	Microsoft.PowerShell.Utility
Cmdlet	Remove-Variable	Microsoft.PowerShell.Utility
Cmdlet	Set-Variable	Microsoft.PowerShell.Utility

Help for a certain cmdlet can be displayed with the command:

>Get-Help <cmdlet-name>

Exercises

3.1. What is a variable in PowerShell?

3.2. What is the basic standard PowerShell notation for denoting variables?

3.3. Why should you try to avoid using spaces and special characters in your PowerShell variable names?

3.4. Can a user change a PowerShell Automatic variable?

3.5 Can a user change a PowerShell Preference variable?

3.6. How can a user get a list of all variables in a PowerShell session?

3.7. PowerShell variables are freely typed. What does this statement mean?

3.8. How is the PowerShell variable data type determined?

3.9. How can a user create and denote a PowerShell variable name that has spaces and special characters?

3.10. How is the scope of variables determined?

3.11. How is the PowerShell Variable: drive created, how does it behave and what does it contain?

3.12. How are PowerShell variable cmdlets in a user’s session listed?

Chapter Summary

The key points of the chapter were:

●         A PowerShell variable is a unit of memory in which values are stored.

●        The three general categories of PowerShell variables are user-created variables, automatic variables, and preference variables.

●         Cmdlet functioning can be greatly enhanced through the use of variables.

●         Variables can be used in commands and expressions.

●         Variables are only available in the scope in which they are created.

●         Variable constitute an important component of scripting.

In the next chapter you will learn about PowerShell pipelines.