Windows PowerShell Blog

I came across this post looking for something entirely different. Truth be told I have not used PowerShell yet!

This clearly presents as a bug and should be fixed. I empathise with the decision that needs to be made, however if it's left as is then the problem will be forever recorded in history as one of those PowerShell peculiarities that should have been fixed long ago. You'll end up inconveniencing more people as the adopted userbase expands.

IMO, it is a bug and should be fixed. The following currently returns true:

 'a' -eq [char]'A'

and this returns false:

 'a' -ceq [char]'A'

So apparently the [char] casting only matters on the left side of the equation? I would expect it to work the same regardless of where I do the casting.

I can understand the dilemma, but my preference would be to move to the more readily apparent idiom where [char]'a' -ieq 'A' results in True.

In a lower-level language, I could be more comfortable arguing that the v1 behavior is of value.  However, in PowerShell I've found such constructs to be more of a hindrance than produing more understandable and readable code.  Additionally, the fix for scripts written to make use of this issue is trivial (a simple cast to [int] will replicate this behavior).

If the v1 behavior is allowed to remain, I would strongly urge for the removal of the -ieq operator for char, as it no longer would apply.

If you want to fix it, make sure it is consistent.

I would prefer to have [char] 'a' -eq 'a' being FALSE as [char] and [string] are like apple and pineapple ;-)))

I find it hard to imagine that this behavious is something someone relies on. After all, it's easily worked around and thus I am strongly in favour of fixing it. As Adrian already pointed out, left this way it would be a language nightmare for the sake of compatibility just as many things in cmd are (and those are often a pain to work with).

Oh, and it should be 'stakeholder' in the article, not 'stackholder', I think :-)

Fixing bugs is the best long term strategy. If I had (in some bizzare mental state) relied on this bug in a script then I would probably like the opportunity to address it.

Knowing the details of the bug, surely it wouldn't be too much of a stretch to create a crawler to itterate through scripts and identify where this fix might break something.

cheers (keep up the good work)

n

IMO, I'd rather see the behavior consistent with string comparisons. If I need to treat a char like an int, I'll cast it that way.

I'm sure this is correct behavior and should not be "fixed". [char] is special data type, different from [string], and it shouldnt be threated equally.

No one will want to 97 be "equal" to 65, this is almost the same case.

Fix it. This isn't the same as 97 being equal to 65; most people expect "a" to always be equal to "A" is case isn't a consideration.

I say fix the bug.  Even though PowerShell is being adopted rapidly, when you get to tens of million active members fixing this issue will not be an option, due to the level of pain customers would experience.

I would say that the -ieq result is a bug, but the -eq result is not.

[char]'a' -eq 'A'  # This should return False (they are not the same)

[char]'a' -ceq 'A'  # This should return False (they are not the same case)

[char]'a' -ieq 'A'  # This should return True (they are the same letter, different case which we asked to ignore)

This is the benefit of having explicitly cased comparisons.  If you want case sensitivity, you can have it.  If you don't want it, you can specify that too.  If there is a script expecting the above -ieq example to return false, then they should have recognized it as a bug.

I say fix it.  Keeping support for "legacy bugs" is a mistake, IMO.

Another "fix it" vote.

Legacy cruft and workarounds do not make for pleasurable experiences 15 years later when a new OS comes out that finally breaks the compatibility.  

I think that it should be fixed so that:

'a' -ieq 'A'

returns true.

There should be a cmdlet/function that gets the value of a character such as:

CharVal('a') -ieq CharVal('A')

returns false.

Fix it.

This bug breaks one of Powershell's great strengths, which is it's consistency.

As some people have pointed out (and I think this should be made clearer in the post, Jeffrey), we have a huge inconsistency here:

PS> 'a' -eq [char]'A'

True

PS> [char]'A' -eq 'a'

False

If A equals B, B should always equal A, no matter what. So it IS a bug and it SHOULD be fixed.

Now comes the second part: in .NET, when you compare a Char with a String, the result is always False. I agree with Domdomz when he says that [char] and [string] are like apple and pineapple. Even though Powershell does and should continue doing a lot of things under the hood to make things easier for everyone, I don't think it should automatically compare Chars with Strings (unless someone comes up with a good example of why that would be useful).

So, my opinion is: it MUST be fixed, but String and Char comparisons should return False.

The argument that a [char] and a [string] should always be unequal is absurd in context - would you argue that an [int] and a [double] are similarly dissimilar, and that:

1.0 -eq 1

should be false?  What about comparing a [double] and a [string]?

"1" -eq 1.0

IMHO, both [char] and [string] are different forms of [text], and thus case insensitive amd sensitive comparisons should be valid.

Yep, fix it.  Just make sure that this behavior change is well documented in the release notes.  It might be nice to have a PowerShell.exe switch that would flag use of changed functionality within a script that could potentially break the script.

I'm not trying to start a flame war here, so let's all relax =).

Let me explain why I think a [char] and a [string] comparison should return false...

1- Powershell is built upon .NET and that's how it works there.

"But, but... Powershell is a scripting language and it doesn't have to follow all the stupid rules of this lower level platform! It should make things easier for the scripters out there!"

Which I would reply to with:

2- Yes, you are right. Powershell should make things easier for everyone (and it does), but making chars equal to strings would not simplify things, in my opinion. Visually, it is compelling to say: [char]'a' is just like 'a', of course they should be equal... They represent the same thing.

But chars don't appear in code like that. They are almost exclusively the return of some method call, like 'string'.ToCharArray(). The only counter intuitive comparison a scripter could face (at least that I can think of) is the "[char]'a' -eq 'a'" example, which, as I said, probably won't be seen in real world scripts.

3- Powershell already treats [char] and [string] differently. When they tried to do too much (making them equal), guess what happened? =)

Let's say 'a' -eq [char]'a' should return $True. In the following code, what should the last line return?

PS> $string = 'a'; $char = [char]'a'

PS> [int]$string -eq [int]$char

In a perfect world, chars and strings should be equal, and all design decisions are easy... But Powershell IS built upon .NET, so maybe it should follow some of their rules, when it's not possible to break them.

Bruno,

Powershell is fundamentally different than C# in the way it 'auto converts' types.  Making Powershell more 'internally consistent' is what makes sense for Powershell.

It would have been wrong for C# to have worked the proposed Powershell way.  It's not 'internally consistent' with strong typing.

Second, language semantics are different than "built on .Net".  There are considerable differences between VB.net and C# and both are built on .Net

Fix it.

Better to fix a few scripts now, that to live with the inconsistency for eternity.

Hello everybody,

I think you should fix it, but not the way you are suggesting. Strong typing inherently means to me that a char is NOT an int. A char is a char, and an int is an int. You can convert one to the other, but they are not the same. So [char]'A' -eq 65 should be false in my opinion (if it not even throws some kind of type mismatch error). Thus, [char]'a' -eq 'a' should be false also, as a char IS NOT a string, and never will be. The benefits of (very) strong typing extend well into the scripting world in my opinion.

Best Regards,

Stefan Falk

i say fix it, but have some sort of "strict" mode, or a function that can peruse a script and point out possible compatibility issues such as this.

Definitely fix it!  This is one of those issues that makes people like me use char objects a lot less (if ever) simply because they don't work as I would expect them to with the standard operators.

If you do the right thing and fix this, please, please, please don't forget this: the contains operator is also broken for char arrays and should have a similar fix applied so that you can properly find out of a character array contains a specific character or not using case-sensitive and case-insensitive comparisons.  This is also broken and very inconsistent in PowerShell, enough so that I don't use character arrays anymore at all because of this issue in v1.

[179] PS↑ C:\> [char[]]'abcde' -contains 'a'

True

[180] PS↑ C:\> [char[]]'abcde' -icontains 'a'

True

[181] PS↑ C:\> [char[]]'abcde' -ccontains 'a'

True # this should be False

[182] PS↑ C:\> [char[]]'abcde' -contains 'A'

False # this should be True

[183] PS↑ C:\> [char[]]'abcde' -icontains 'A'

False # this should be True

[184] PS↑ C:\> [char[]]'abcde' -ccontains 'A'

False

--

Kirk Munro [MVP]

Poshoholic

http://poshoholic.com

My opinion: fix this anyway!

If old scripts break one should always be able to run them using PowerShell V1. PowerShell V2 should have PS2 file extension anyway. Languages will always change.

--

greetings

dreeschkind

I absolutly agree with dreeschkind. Change the file extension to ps2 and fix the bug.

I can't repeat it often enough: Change the file extension!

This should be fixed.  Chars should be chars, not some cute way to refer to an int.

This looks like a holdover to the c language where just about everything could be interpreted as an int.  You don't intend PowerShell to become c, do you?  PLEASE say no.

c was (is) a fine language for those who can handle it properly.  But, that doesn't mean every language that comes after must emulate it.  There are plenty of quirks in c that would be much better left behind.

I repeat - chars should be chars with their own existence and behavior quite outside of any other data type.  Fix it and let the scripts break.  It's the right thing to do.

I don't think you should emphasize backwards compatibility in this case.

If char 'a' and 'A' both are converted to the same integer something is contraintuitive anyway (I'd expect one to be 65 and the other 97 - flipping the 6th bit was the way to change case on ascii characters).

If it break scripts then ship the 2.0 release with a clear warning that users should read the changelog and then maybe also ship a script that can browse a folder and find scripts that has the problem.

Fix it. My opinion is do the right thing. If one thing is wrong, correct it.