-
Notifications
You must be signed in to change notification settings - Fork 382
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PSSA should have a new rule to check for properly used Process blocks #1571
Comments
Meta: Should I have broken this into two issues? (I submitted on the wrong account) |
This is behaving as expected.
In the example you give, Importantly, the PowerShell parser (the same one that parses your script on execution) is what makes this distinction before PSScriptAnalyzer does any processing. By the time the script gets to PSScriptAnalyzer, there's a large structural distinction between a
In the first case, a You can see this in the absence of PSScriptAnalyzer by trying to define a function like this directly in PowerShell. When
When
So the formatting here has not mutated your code to change its meaning; it still does the same thing as the original script you wrote. A remaining question is whether it's worth investing in a rule to warn about using commands that shadow keywords like this. |
PSAvoidUsingCmdletAliases
and CheckParameter
damage code when code is outside process blocks
For some cases the formatter is changing code where it cannot run. Rules that trigger this are:
PSUseConsistentWhitespace.CheckParameter
when$True
PSAvoidUsingCmdletAliases
when$True
The source script triggering this bug is not valid, however
PSAvoidUsingCmdletAliases
:pwsh
will execute this with no errors (It runs normally, it never assigns$x
)CheckParameter
: This code is broken,pwsh
will not execute thisPossible Cause of
PSAvoidUsingCmdletAliases
I think the cause is the script reaches a statement that is not inside a
begin/process/end
block -- so it assumes the function is a non-pipeline function. In that context,process
is not a keyword but an identifier. It replacesprocess
withGet-Process
(which would the correct behavior if it was a normal function)Invoke-ScriptAnalyzer
has the same behavior.Potential fix for
PSAvoidUsingCmdletAliases
?begin/process/end
blocks.begin/process/end
statements, then treat it as a pipeline function?Steps to reproduce
Expected behavior
Indent and replace aliases.
Actual behavior
Indent, and replaces keyword as if it was not in the keyword context.
Another example not using pipeline functions
Steps to reproduce
Expected behavior 2
Give an error, or don't mutate code
Actual behavior 2
Environment data
The text was updated successfully, but these errors were encountered: