UseDeclaredVarsMoreThanAssignments should ignore $Env:

[javydekoning]

Hi,

I'm using the following code in from time to time to refresh Environment/Path variables without restarting the OS/Shell:

$env:Path = [Environment]::GetEnvironmentVariable('Path','Machine')   

I think this has proper use cases in software installs and so on.

[seanchambersgray]

+1 to this - I've experienced this due to setting $env:psmodulepath for the duration of a script. This obviously doesn't get read, so triggers this rule.

[bergmeister]

This is already fixed in the current version 1.16.1 i.e. Invoke-ScriptAnalyzer -ScriptDefinition '$env:Path = [Environment]::GetEnvironmentVariable(''Path'',''Machine'')' does not return a warning any more. The relevant line of code that does this is here. Will therefore close unless someone can prove otherwise.

[LaurentDardenne]

A remark, not to prove the opposite but to take into account the multiple assignment:

#PSScriptAnalyzer 1.16.1     
#PS 5.1.14409.1012

Invoke-ScriptAnalyzer -ScriptDefinition '$env:Path =$Copypath= [Environment]::GetEnvironmentVariable(''Path'',''Machine'')'
#Warning for copypath

Invoke-ScriptAnalyzer -ScriptDefinition '$env:Path =$Copypath= [Environment]::GetEnvironmentVariable(''Path'',''Machine'');$copypath +="c:\temp\"'
#Warning for Path

[bergmeister]

The first one looks correct to me because $Copypath is not used. The second should not produce any warnings though although if I modify it slightly then it does not give warnings:
Invoke-ScriptAnalyzer -ScriptDef inition '$env:Path =$Copypath= [Environment]::GetEnvironmentVariable(''Path'',''Machine'');get-foo $copypath'
Multiple assignments in general (not only related to env variables) sounds like a separate issue to me.

[mattpwhite]

This is still broken for me, here's a repro (does not complain outside a function):

PS C:\> cat C:\local\sa.ps1
function Show-Bug {
    $env:example = 'a'
}
PS C:\> Invoke-ScriptAnalyzer C:\local\sa.ps1

RuleName                            Severity     ScriptName Line  Message
--------                            --------     ---------- ----  -------
PSUseDeclaredVarsMoreThanAssignment Warning      sa.ps1     2     The variable 'example' is assigned but never used.
s


PS C:\> get-module psscriptanalyzer

ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Script     1.16.1     PSScriptAnalyzer                    {Get-ScriptAnalyzerRule, Invoke-Formatter, Invoke-ScriptAnalyzer}

PS C:\> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.15063.966
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.15063.966
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

[lzybkr]

@bergmeister - Please reopen - I still see this warning in 1.16.1 when the assignment occurs in a function or scriptblock, e.g.

$x = { $env:foo = 1 }
& $x

[bergmeister]

Let me summarise:

• The example given in the issue statement $env:Path = [Environment]::GetEnvironmentVariable('Path','Machine') does not produce a warning any more in the development version of PSSA.
• But the example from the recent comment 'function Show-Bug {$env:example = ''a''}' does give a warning, will therefore re-open.
• The example $x = { $env:foo = 1 }; & x by @lzybkr seems to be also related to PSUseDeclaredVarsMoreThanAssignments is not aware of the scriptblock context (invocation or dot-sourcing) #938

[lzybkr]

@bergmeister - Assignments to drive qualified variables should never get a warning regardless of the context. env:, function:, hklm:, etc. If #938 is related to my example, it shouldn't be.

[bergmeister]

@lzybkr Sorry, you're right. When I first copy pasted your example then I also saw a warning on $x, which I attributed to the other referenced issue but it turns out that it was only because one dollar sign was missing in the example.
I opened a PR with a fix that fixes all examples given in this issue.