tl;dr
In order to update the $BaseHomeFolderPath
variable in the script scope (or any scope other than the local one), you must reference it in that scope explicitly:
$script:BaseHomeFolderPath = '\path1users'
Otherwise, without a scope specifier such as $script:
, you'll implicitly create a new variable by that name in the current scope, which in your case is the child scope in which your event handlers run.
In PowerShell, when you assign to a variable with $var = ...
, you either:
The tricky part is that even though child scopes see variables created in parent scopes and can get their value by name only, assigning to them by name only creates a new, scope-local variable, and that new variable then shadows the original one in the current scope and all child scopes.
A simple demonstration, using call operator &
to execute a script block ({ ... }
) in a child scope:
$var = 'parent'
"in parent: before: $var"
& {
"in child: before: $var" # sees $var from parent scope
$var = 'child' # creates new $var in current scope
"in child: after: $var" # sees new $var, which shadows the parent's
}
"in parent: after: $var" # still has original value
This prints:
in parent: before: parent
in child: before: parent
in child: after: child
in parent: after: parent
Note:
In addition to fixed-target scope specifiers $script:
and $global:
, you can use the Get-Variable
/ Set-Variable
cmdlets with the -Scope
parameter to target variables in scopes relative to the current one (up the call stack).
To promote modularity and maintainability, it's generally better to avoid accessing variables across scope boundaries - best to pass values around instead.
For more information, see:
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…