Prerequisites
Steps to reproduce
This is a sub-issue of #25242.
The cmdlet Where-Object does not respect explicit $false values for any of its 31 operator switch parameters. This affects all comparison and logical operator switches.
Example with -EQ:
$data = @(
[PSCustomObject]@{ Name = 'Alice'; Age = 25 }
[PSCustomObject]@{ Name = 'Bob'; Age = 30 }
)
$result = $data | Where-Object Name -EQ:$false
$result.Count
Example with -GT:
$result = $data | Where-Object Age -GT:$false
$result.Count
Expected behavior
PS> $result = $data | Where-Object Name -EQ:$false
PS> $result.Count
2
When -EQ:$false is specified, the -EQ operator should not be active. The cmdlet should fall back to default boolean evaluation of the property value, returning all objects where Name is truthy (non-empty strings).
Similarly for other operators, -[Operator]:$false should behave as if the operator switch was not specified at all.
Actual behavior
PS> $result = $data | Where-Object Name -EQ:$false
PS> $result.Count
0
The -EQ:$false is incorrectly interpreted as -EQ $false, comparing the Name property against the boolean value $false instead of disabling the -EQ operator. This causes the filter to return no results because no Name values equal $false.
Affected parameters
All 31 operator switch parameters are affected:
| Category |
Parameters |
| Equality |
-EQ, -CEQ, -NE, -CNE |
| Comparison |
-GT, -CGT, -GE, -CGE, -LT, -CLT, -LE, -CLE |
| Pattern |
-Like, -CLike, -NotLike, -CNotLike, -Match, -CMatch, -NotMatch, -CNotMatch |
| Containment |
-Contains, -CContains, -NotContains, -CNotContains, -In, -CIn, -NotIn, -CNotIn |
| Type |
-Is, -IsNot |
| Logical |
-Not |
Error details
No error is thrown. The cmdlet executes but misinterprets the explicit $false value as an operand rather than as a directive to disable the switch.
Environment data
PS> $PSVersionTable
Name Value
---- -----
PSVersion 7.5.4
PSEdition Core
GitCommitId 7.5.4
OS Microsoft Windows 10.0.26100
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Visuals
No response
Prerequisites
Steps to reproduce
This is a sub-issue of #25242.
The cmdlet
Where-Objectdoes not respect explicit$falsevalues for any of its 31 operator switch parameters. This affects all comparison and logical operator switches.Example with
-EQ:Example with
-GT:Expected behavior
When
-EQ:$falseis specified, the-EQoperator should not be active. The cmdlet should fall back to default boolean evaluation of the property value, returning all objects whereNameis truthy (non-empty strings).Similarly for other operators,
-[Operator]:$falseshould behave as if the operator switch was not specified at all.Actual behavior
The
-EQ:$falseis incorrectly interpreted as-EQ $false, comparing theNameproperty against the boolean value$falseinstead of disabling the-EQoperator. This causes the filter to return no results because noNamevalues equal$false.Affected parameters
All 31 operator switch parameters are affected:
-EQ,-CEQ,-NE,-CNE-GT,-CGT,-GE,-CGE,-LT,-CLT,-LE,-CLE-Like,-CLike,-NotLike,-CNotLike,-Match,-CMatch,-NotMatch,-CNotMatch-Contains,-CContains,-NotContains,-CNotContains,-In,-CIn,-NotIn,-CNotIn-Is,-IsNot-NotError details
No error is thrown. The cmdlet executes but misinterprets the explicit
$falsevalue as an operand rather than as a directive to disable the switch.Environment data
Visuals
No response