Forum Discussion
pooja520
Microsoft
MicrosoftPowershell: how to use an if condition with true false
Highlighted , how is $ True is equal to false?
Same way, why does typecasting 'False' to boolean is evaluating to true?
What is the right way to use if condition that can r...
PowerShell is not strongly-typed language like C#, where the compiler wouldn't even let you run a test like [bool] -eq [string]. Where PowerShell does allow such operations, they come with behaviours you need to know about.
What your first test ($Stat -eq 'fal') is testing is for the existence (i.e. present and not null) of the right of the operator - since the types themselves don't match - and comparing that to the value on the left. So, rather than:
$Stat -eq 'fal';
You're actually comparing (since 'fal' both exists and is not null):
$Stat -eq $true;
Hence the result is $true.
Here's my own example illustrating this very point using an even more complex type on the right-hand side:
Now, if you swap the values around, you'd expect to get the same outcome, but you don't. This is because PowerShell is now testing for equality against the complex ActiveDirectorySite class, which the Boolean isn't going to match (since the test is something called a reference equality test - but this isn't important.)
So, this brings me to the crux of your issue: how can you reliably test a Boolean against another Boolean? (as distinct from your example that is a Boolean against a String.)
I'd posit two basic ways though there are more:
- Swap the Boolean to be on the right side of the operator, with the object you're comparing to the left;
- Use the .NET .Equals() method on the Boolean object to assess the object being checked.
PowerShell's implicit existence testing can be quite a handy feature, but in the case of working with the Boolean type also requires a bit more care - and testing - to avoid unintended outcomes.
Cheers,
Lain
Getting away from the topic of why you get the opposite result to what you may have expected and answering the question you raised of:
"What is the right way to use if condition that can receive $True or 'True or $False or 'False'"
There's a number of ways, but I would recommend keeping a string constant to the left, with the variable being checked to the right of the operand, like this:
if ("true" -eq $MyVariable)
This forces the right-hand side to be implicitly converted to the data type of the left hand side, which if you recall is possible because the Boolean data type contains a .ToString() method (but you cannot convert in the opposite direction.)
As you can see from the example below, this produces reliable outcomes.
If you are quite fussy about your data type standards and prefer to use the Boolean data for the actual comparison, and you want to cope gracefully with receiving a string variable, then I'd recommend the Boolean.TryParse() approach.
Cheers,
Lain
pooja520Microsoft
MicrosoftThis thread is an eye opener. Brilliant teaching in there. Learnt important internal and now lesser anxious with 'what the heck is going on'. Thanks for being such knowledgeable, humble and an amazing teacher all at the same time.
However, the reasons also makes me think whether to stick to powershell or go for more clearer langs.
Eg. I have one more weird behavior related to function returning, that would never happen in an programming lang. Will create a separate thread on it with the mini snippet.
Thanks a ton for your time and efforts explaining current one.
However, the reasons also makes me think whether to stick to powershell or go for more clearer langs.
Eg. I have one more weird behavior related to function returning, that would never happen in an programming lang. Will create a separate thread on it with the mini snippet.
Thanks a ton for your time and efforts explaining current one.
Anytime!
There's not many scenarios as obscure as the Boolean one, and in a similar spirit to JavaScript, it's become incredibly pervasive over the years. So, I'd say play with and get to know it, and treat it like the Swiss army knife you pull out to get short tasks taken care of - particularly if you're coming from a C# background.
It's not my go-to choice for larger bodies of work, but for short projects and general administration, it's a pretty handy tool to be able to call upon.
Cheers,
Lain
