Redirection is treated as PSPossibleIncorrectUsageOfRedirectionOperator

[cj-wong]

Before submitting a bug report:

• Make sure you are able to repro it on the latest released version
• Perform a quick search for existing issues to check if this bug has already been reported

Steps to reproduce

Line that triggers this message:

if (Get-ScheduledTask -TaskName $name 2>$null)

Expected behavior

No errors

Actual behavior

PSPossibleIncorrectUsageOfRedirecti Warning      Tasks.ps1  64    Did you mean to use the redirection operator '>'? The
onOperator                                                        comparison operators in PowerShell are '-gt' (greater than)
                                                                  or '-ge' (greater or equal).

If an unexpected error was thrown then please report the full error details using e.g. $error[0] | Select-Object *

Environment data

> $PSVersionTable

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

> (Get-Module -ListAvailable PSScriptAnalyzer).Version | ForEach-Object { $_.ToString() }

1.21.0

[bergmeister]

Why do you expect no errors? The whole point of the rule is to warn around possible unintentional usage of redirect operator (often the user meant to use -gt operator) in an if statement. Therefore if you know that this is what you want, then you are meant to suppress it, this way you can also document the rev of the warn in code.
The only thing we could try and see if we can do is whether we can detect that a specific stream redirection is happening like in this case because it's more about in that case that the user did it deliberately.

[cj-wong]

I opened this issue because I thought the pattern matching used by the rule is too broad. If I'm expected to suppress every error that comes my way (and that's if I know that what I'm doing doesn't apply to the rule), doesn't that reduce the utility of this tool? I already ignore several rules that don't apply, so adding additional lines to suppress these errors (which is already very verbose) only increases noise in my code. If this isn't in the scope of an issue, I'll close the issue, no problem.

[StevenBucher98]

We have labeled this as an enhancement because the rule is behaving as designed but your suggestion is one we will consider for future feature work.

[bergmeister]

@StevenBucher98 we had a similar discussion when the rule was created. Without a constructive idea HOW to do it better, I don't think it's worth the issue TBH. Because the rule is warning around potentially not intended use of redirection operator and there is nothing I can think of to infer whether usage is rather intentional or not.

[cj-wong]

I've discovered a better way to handle error messages (-ErrorAction SilentlyContinue), so I'm closing this.