Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Explicit creation of preference variables in descendant scopes should be appropriately type-constrained, as in the global scope / according to the definition of the preference variable #3483

Copy link
Copy link
@mklement0

Description

@mklement0
Issue body actions

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
Reactions are currently unavailable

Metadata

Metadata

Assignees

No one assigned

    Labels

    Issue-Discussionthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassifthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassifIssue-Enhancementthe issue is more of a feature request than a bugthe issue is more of a feature request than a bugResolution-No ActivityIssue has had no activity for 6 months or moreIssue has had no activity for 6 months or moreWG-Languageparser, language semanticsparser, language semantics

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      Morty Proxy This is a proxified and sanitized view of the page, visit original site.