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
This was reported in the UK PowerShell Slack user group get-psuguk by @pauby
This bug was initially reported for version 1.16.1 but even with the recent PR 909 that was merged today, this strange behaviour happens.
cd $PSScriptAnalyzerCheckoutInvoke-ScriptAnalyzer-ScriptDefinition gci -Settings (join-path ((get-location).path) 'Engine\Settings\ScriptingStyle.psd1') -Verbose
Expected behavior
No warning and only the 2 rules in the settings file are being used.
VERBOSE: Using settings file at C:\Users\cberg\git\PSScriptAnalyzer\Engine\Settings\ScriptingStyle.psd1.
VERBOSE: Analyzing Script Definition.
VERBOSE: Running PSAvoidUsingWriteHost rule.
VERBOSE: Running PSProvideCommentHelp rule.
Actual behavior
The settings file is ignored and all rules are being applied
>$PSVersionTable
Name Value
---------
PSVersion 5.1.16299.248
PSEdition Desktop
PSCompatibleVersions {1.0,2.0,3.0,4.0...}
BuildVersion 10.0.16299.248
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
Name Value
---------
PSVersion 6.0.1
PSEdition Core
GitCommitId v6.0.1
OS Microsoft Windows 10.0.16299
Platform Win32NT
PSCompatibleVersions {1.0,2.0,3.0,4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0> (Get-Module-ListAvailable PSScriptAnalyzer).Version |ForEach-Object { $_.ToString() }
1.16.1# Happens also using latest code at hash d4ba9470fa5677ea95266b8334ebaf8681650b6c
Remarks
What is weird is the fact that this does not happen if the object being passed to the cmdlet is specified as a string "$((join-path ((get-location).path) 'Engine\Settings\ScriptingStyle.psd1'))". This is weird because the object is already a string and when assigning the object to a variable and doing an equal comparison to its literal string, then it reports true...
The text was updated successfully, but these errors were encountered:
bergmeister
changed the title
SettingsFile cannot be found in a special case when specifying -Setting parameter object in a certain way
Settings file cannot be found in a special case when specifying -Setting parameter object in a certain way
Feb 28, 2018
A quick investigation shows that this might be a quirk/artifact of PowerShell's parser because in the BeginProcessing() part, the object does not seem to get fully resolved and is therefore not a string yet. Maybe we need to try to convert the expression to a string as a last resort...
Steps to reproduce
This was reported in the UK PowerShell Slack user group
get-psuguk
by @paubyThis bug was initially reported for version
1.16.1
but even with the recent PR 909 that was merged today, this strange behaviour happens.Expected behavior
No warning and only the 2 rules in the settings file are being used.
Actual behavior
The settings file is ignored and all rules are being applied
Environment data
Remarks
What is weird is the fact that this does not happen if the object being passed to the cmdlet is specified as a string
"$((join-path ((get-location).path) 'Engine\Settings\ScriptingStyle.psd1'))"
. This is weird because the object is already a string and when assigning the object to a variable and doing an equal comparison to its literal string, then it reports true...The text was updated successfully, but these errors were encountered: