Scopes

Scope is a description of the visibility of a function or variable within PowerShell. This is a means of controlling access to variables and functions. Unless you explicitly request otherwise, generally variables can be read and changed only within the scope where they were originally created. Also, they'll only be accessible to cmdlets running in the same scope. Consider the previous example of running a script:

 PS C:\>. Myscript arg1 arg2 

This example shows why it was so important to specify the period - to ensure that the script would run in the current scope, thus having access to any variables or functions already declared within that scope. If we hadn't used the period, PowerShell would take its default action of creating a new scope for the script. This technique of preceding the script name with a period and a space is called dot sourcing, which essentially makes the script behave as if you are typing each line of the script directly into the PowerShell shell.

Unless you use dot sourcing, by default all scripts are run in a newly created scope. Child scopes, or scopes created by another scope, can read variables from the parent scope, but cannot change them as easily. Parent scopes cannot access child scope variables in any way.

When you start a new instance of PowerShell, you're working in the global scope. Any child scope can access global scope variables such as environment variables. However, they must explicitly label the variable as global in order to do so. We'll touch on this in greater detail later.

Scope Names

The global scope is simply named global, while the scope of an executing script is named script. We'll reveal other special scope names as we use them elsewhere in the book.

Here's an example of scopes. Say a script declares a variable named $var. A function runs, and also declares $var, which means there are two copies of $var in existence: one in the script's scope and one in the function's scope. Because the function is contained within the script, its scope is a child of the script's scope. That means the function can access script-level variables by referring to $script:var if it chooses to do so. That is, the function can access the name of the scope (script) and the name of the variable from that scope (var). More information on functions is coming up next.

Variables can also be declared as private, which means they're accessible only from the current scope, and not from within child scopes. The following example declares a private variable named var:

 PS C:\>$private:var 

Here's another example. Suppose you create a variable in the basic shell, without running a script. That variable exists in the shell's global scope. If you then run a script, that script gets it own scope, which is a child of the shell itself. Therefore, by default, the script has read access to the variable you declared in the shell because the script's scope is a child of the shell's scope.

We're going to cover scopes in a lot more detail in Chapter 4 since they're somewhat confusing at first, and since they can dramatically affect the way your scripts run.