You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
PSAvoidAssignmentToAutomaticVariable Errors on validateset #1970
That's why, in the terminal, when I use the parameter completion that ValidateSet facilitates, I get the string options (not $true or $false):
But accepting the suggestions, the function errors:
New-SlackMessage: Cannot process argument transformation on parameter 'UnfurlLinks'. Cannot convert value "System.String" to type"System.Boolean". Boolean parameters accept only Boolean values and numbers, such as $True, $False, 1 or 0.
Which makes me think the function needs some work if it's using ValidateSet to ensure that a declared Boolean value is either true or false 🤔.
That all said, you're correct and it's not assignment. The rule is probably checking all parameters for any variable expressions and alerting if a reserved name is used.
That's why, in the terminal, when I use the parameter completion that ValidateSet facilitates, I get the string options (not $true or $false):
But accepting the suggestions, the function errors:
New-SlackMessage: Cannot process argument transformation on parameter 'UnfurlLinks'. Cannot convert value "System.String" to type"System.Boolean". Boolean parameters accept only Boolean values and numbers, such as $True, $False, 1 or 0.
Which makes me think the function needs some work if it's using ValidateSet to ensure that a declared Boolean value is either true or false 🤔.
That all said, you're correct and it's not assignment. The rule is probably checking all parameters for any variable expressions and alerting if a reserved name is used.
I'll take a look at this.
it's not that $true and $false are being converted to a string. It's that they are constants from powershell's perspective, so they don't cause a parsing error. For example, if you use $HOME, you wouldn't get past the parsing stage since $HOME is not a constant from PowerShell's perspective. There are a very small set of variables which PowerShell considers constant.
This attribute is really looking for a set of constant strings
Activity
liamjpeters commentedon Mar 27, 2024
This is a strange one.
Ultimately
ValidateSetonly accepts a string array of valid values, so I guess it's going to cast$Trueand$Falsetostringand be left with'True'and'False'.That's why, in the terminal, when I use the parameter completion that
ValidateSetfacilitates, I get the string options (not$trueor$false):But accepting the suggestions, the function errors:
Which makes me think the function needs some work if it's using
ValidateSetto ensure that a declaredBooleanvalue is either true or false 🤔.That all said, you're correct and it's not assignment. The rule is probably checking all parameters for any variable expressions and alerting if a reserved name is used.
I'll take a look at this.
JamesWTruher commentedon Mar 27, 2024
it's not that
$trueand$falseare being converted to a string. It's that they are constants from powershell's perspective, so they don't cause a parsing error. For example, if you use$HOME, you wouldn't get past the parsing stage since$HOMEis not a constant from PowerShell's perspective. There are a very small set of variables which PowerShell considers constant.This attribute is really looking for a set of constant strings
liamjpeters commentedon Mar 28, 2024
Thanks for the explanation James Truher (@JamesWTruher). Makes sense!
bergmeister commentedon Apr 9, 2024
Thanks for raising this and opening PR, will review