Forum Discussion
Powershell ignores NULL characters in string comparison?
I stumbled across this phenomenon in Powershell 7.3.3:
Turned out that $a contained a NULL character (0x00) at the end, which caused the error with ParseExact. But why does $a -eq $b return True?
I'd suggest this isn't going to be accepted as a bug as it's related to culture. You'll find this feature (or bug) across all PowerShell versions - including Windows PowerShell from which I've produce the examples below (showing culture versus ordinal.)
Intent also matters as PowerShell is not a direct substitute for things like C# and has numerous "user friendly" interpretations going on that you just won't find in a strict language.
I'd say if you're already playing with .NET objects (as you are with DateTime), you should continue doing so by using the .Equals() method where appropriate, or perhaps even .Replace() to remove null characters if that's a concern.
The null character alone has special meaning to strings in C-like languages, so that'd be the only character you'd need to watch out for in a string equality test.
Rather than something being "fixed" in PowerShell, it would be "better" (I'm not convinced this one scenario warrants the effort but I'm speaking in hypotheticals here) to add yet another equality operator (currently, we have "eq", "ceq" and "ieq") that performs an ordinal comparison.
Cheers,
Lain
- Best report this on GitHub.
I'd suggest this isn't going to be accepted as a bug as it's related to culture. You'll find this feature (or bug) across all PowerShell versions - including Windows PowerShell from which I've produce the examples below (showing culture versus ordinal.)
Intent also matters as PowerShell is not a direct substitute for things like C# and has numerous "user friendly" interpretations going on that you just won't find in a strict language.
I'd say if you're already playing with .NET objects (as you are with DateTime), you should continue doing so by using the .Equals() method where appropriate, or perhaps even .Replace() to remove null characters if that's a concern.
The null character alone has special meaning to strings in C-like languages, so that'd be the only character you'd need to watch out for in a string equality test.
Rather than something being "fixed" in PowerShell, it would be "better" (I'm not convinced this one scenario warrants the effort but I'm speaking in hypotheticals here) to add yet another equality operator (currently, we have "eq", "ceq" and "ieq") that performs an ordinal comparison.
Cheers,
Lain
LainRobertson Thanks, yes, that's what I learned now. And of course I could easily fix my script with
-replace "\x00",""Still it seems kinda illogical because "equal" means "equal" to me, so it's hard to grasp that two strings can have different lengths and work differently but still be "equal." I'd probably call it "equivalent" instead.
But anyway, at least we know now why it is like it is.- Was accepted as a documentation inaccuracy and fixed: https://github.com/MicrosoftDocs/PowerShell-Docs/issues/9982
