Currently, preference variables, such as $VerbosePreference, are only predefined in the global scope, where they are type-constrained, such as to [System.Management.Automation.ActionPreference], which ensures that only valid values can be assigned to them.
Some preference variables, such as $OFS, aren't even predefined in the global scope, although their type (and default value) is known, as described in Get-Help about_Preference_Variables.
By contrast, assigning to a preference variable in any descendant scope implicitly creates a new variable that is not type-constrained, which effectively allows assigning invalid values.
Therefore, assigning invalid values in scripts may go unnoticed.
(It seems that PowerShell quietly applies a given preference variable's default value in the event of encountering an invalid value.)
Steps to reproduce
$VerbosePreference = 'ThisIsAnInvalidValue'
& { $VerbosePreference = 'ThisIsAnInvalidValue' }
Expected behavior
Ideally, both commands would complain about the inability to convert string 'ThisIsAnInvalidValue' to type [System.Management.Automation.ActionPreference]
Actual behavior
-
The first command fails, as desired, because the top-level $VerbosePreference is type-constrained to [System.Management.Automation.ActionPreference], and converting string 'ThisIsAnInvalidValue' to that type fails.
-
The 2nd command is quietly accepted, because assigning to $VerbosePreference in the child scope created by & implicitly creates a new, local variable that isn't type-constrained, so it effectively becomes a [string] value that cannot be converted to a legal [System.Management.Automation.ActionPreference] value.
Environment data
PowerShell Core v6.0.0-alpha (v6.0.0-alpha.17) on Darwin Kernel Version 16.5.0: Fri Mar 3 16:52:33 PST 2017; root:xnu-3789.51.2~3/RELEASE_X86_64
Currently, preference variables, such as
$VerbosePreference, are only predefined in the global scope, where they are type-constrained, such as to[System.Management.Automation.ActionPreference], which ensures that only valid values can be assigned to them.Some preference variables, such as
$OFS, aren't even predefined in the global scope, although their type (and default value) is known, as described inGet-Help about_Preference_Variables.By contrast, assigning to a preference variable in any descendant scope implicitly creates a new variable that is not type-constrained, which effectively allows assigning invalid values.
Therefore, assigning invalid values in scripts may go unnoticed.
(It seems that PowerShell quietly applies a given preference variable's default value in the event of encountering an invalid value.)
Steps to reproduce
Expected behavior
Ideally, both commands would complain about the inability to convert string
'ThisIsAnInvalidValue'to type[System.Management.Automation.ActionPreference]Actual behavior
The first command fails, as desired, because the top-level
$VerbosePreferenceis type-constrained to[System.Management.Automation.ActionPreference], and converting string'ThisIsAnInvalidValue'to that type fails.The 2nd command is quietly accepted, because assigning to
$VerbosePreferencein the child scope created by&implicitly creates a new, local variable that isn't type-constrained, so it effectively becomes a[string]value that cannot be converted to a legal[System.Management.Automation.ActionPreference]value.Environment data