Decision Input Requested: -EQ with Characters

re: Decision Input Requested: -EQ with Characters

Doug — Tue, 23 Sep 2008 05:05:43 GMT

I like that PowerShell lets me mine data quickly. I don't have to think about case.

$_.Ticker -match 'ibm'

I'd prefer consistency and fix scripts that had issues.

Otherwise I have to keep lots of rules in my head depending on the type of data I am comparing.

re: Decision Input Requested: -EQ with Characters

Adrian — Tue, 23 Sep 2008 05:46:34 GMT

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.

re: Decision Input Requested: -EQ with Characters

Andy — Tue, 23 Sep 2008 05:51:04 GMT

Feel it should remain as it is:

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

False

Since this is surely True, that 'a' and 'A' are not equivalent ...

Regards

Andy

re: Decision Input Requested: -EQ with Characters

Pete — Tue, 23 Sep 2008 06:01:49 GMT

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.

re: Decision Input Requested: -EQ with Characters

Greg Lyon — Tue, 23 Sep 2008 06:25:09 GMT

I think that it should be fixed.

re: Decision Input Requested: -EQ with Characters

PowerShellTeam — Tue, 23 Sep 2008 06:28:10 GMT

@Andy:

"Since this is surely True, that 'a' and 'A' are not equivalent ..."

yes - I didn't make the point well (I've now updated the article). The problem is that this is ALSO the case when you use -IEQ

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

False

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

False

<Update: Notice that you get FALSE whether you use -eq (EQUALS) or -ieq (CASE INSENSITIVE EQUALS) >

jps

re: Decision Input Requested: -EQ with Characters

Joel "Jaykul" Bennett — Tue, 23 Sep 2008 07:50:51 GMT

I say "fix" it.

As a developer, I don't think it's really a bug to compare int values ... particularly when you're forcing the comparison of CHAR instead of string. You have to be really deliberate to get a char in PowerShell, so it should be obvious... and my first inclination was to say leave it, but ...

If you leave it, then the only option people have to get a case INsensitive comparison is a rather expensive conversion to strings ... whereas if you fix it, we can always deliberately say -ceq ...

Also, consider the inconsistency of

PS> [char]$c = "a"

PS> switch($c) {

>> "A" { "Big A" }

>> "a" { "Little A" }

>> }

Big A

Little A

PS> $c -eq "A"

False

... that's really trippy :)

re: Decision Input Requested: -EQ with Characters

Alex B Chalmers — Tue, 23 Sep 2008 08:11:04 GMT

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.

re: Decision Input Requested: -EQ with Characters

Alex — Tue, 23 Sep 2008 08:28:18 GMT

Jeffrey,

Compliments on the great product, with Powershell we really get the sense of power,

now I always feel I can do the things I need to do, when before we regulary got stuck or had to fall back to calling 3rd party tools or creating awkward workarounds!

My opinion about this issue:

It's a bug, so it's probably better fixed in v2.0 then in version v5.0, and there will be lots more scripts broken by that time.

It would probably help to document the change really well in the release notes.

re: Decision Input Requested: -EQ with Characters

Domdomz — Tue, 23 Sep 2008 09:06:55 GMT

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 ;-)))

re: Decision Input Requested: -EQ with Characters

nikb — Tue, 23 Sep 2008 11:00:51 GMT

Its a bug its need fixing. I do agree with an earlier statement that if you don't fix it, it will haunt Powershell during its lifetime.

Better to fix it now v2 than i v3 :-)

re: Decision Input Requested: -EQ with Characters

Johannes Rössel — Tue, 23 Sep 2008 11:16:06 GMT

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 :-)

re: Decision Input Requested: -EQ with Characters

David Moravec — Tue, 23 Sep 2008 12:35:38 GMT

As mentioned before, both -eq and -ieq has the same output for those four:

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

False

'a' -eq 'A'

True

[char]'a' -eq 'A'

False

'a' -eq [char]'A'

True

<Ups, I dived deep into this - have full screen of -eq, -ieq, ceq :)>

Frankly - I am a PowerSheller short time and till now haven't trouble with comparison (it worked as I expected). As I now tested really a lot of comparison, for me current state is OK. Maybe except points three and four in my examples - this is for me strange.

re: Decision Input Requested: -EQ with Characters

n3llyb0y — Tue, 23 Sep 2008 13:00:12 GMT

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)

re: Decision Input Requested: -EQ with Characters

JeremyG — Tue, 23 Sep 2008 13:57:14 GMT

Clearly a bug and should be fixed.

For the justification I will say that Powershell is still a very young language, and while this may create a couple of headaches right now.....imagine what it would be like if this stays the same for YEARS and becomes a quirk of the language.

re: Decision Input Requested: -EQ with Characters

Mike — Tue, 23 Sep 2008 15:29:56 GMT

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.

re: Decision Input Requested: -EQ with Characters

Mark — Tue, 23 Sep 2008 15:32:34 GMT

I think this is clearly a bug and should be fixed.

Not only is

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

False

but

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

False

IMO this behavior is simply wrong and should be fixed in PS.

re: Decision Input Requested: -EQ with Characters

Xaegr — Tue, 23 Sep 2008 15:50:19 GMT

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.

re: Decision Input Requested: -EQ with Characters

Elan — Tue, 23 Sep 2008 16:53:41 GMT

Definitely a bug and should be fixed.

re: Decision Input Requested: -EQ with Characters

Don Jones — Tue, 23 Sep 2008 17:26:06 GMT

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.

re: Decision Input Requested: -EQ with Characters

Jason Fossen — Tue, 23 Sep 2008 17:40:42 GMT

[char]'a' -ieq 'A'

This should eval to TRUE since it's what 90% of administrative scripters (the main target audience) would expect. Even if more experienced C/C++/C# coders might expect otherwise, those coders will quickly find the issue in their scripts and accomodate; the admin scripters, on the other hand, are more likely to struggle and blame PowerShell/Microsoft for it (which hurts adoption of PowerShell).

As for breaking scripts, I've done a ton of them and I doubt a single one would be broken by this change.

Thanks for asking the group! Looking forward to PowerShell 2.0!

re: Decision Input Requested: -EQ with Characters

Chris Kuntz — Tue, 23 Sep 2008 17:51:06 GMT

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.

re: Decision Input Requested: -EQ with Characters

MikeDub — Tue, 23 Sep 2008 18:13:34 GMT

Short Answer - Fix it

Have to laugh..My bookmark in Bruce's book (PowerShell in Action) is actually on page 107. Just a couple pages after the discussion on 'Comparisons and case-sensitivity.

So, with that being said - it should be clear that I'm JUST getting started with PowerShell, as I would believe many are and will be soon. Would rather see a fix in place before I really get into my PowerShell scripting.

re: Decision Input Requested: -EQ with Characters

Jason Archer — Tue, 23 Sep 2008 19:00:27 GMT

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.

re: Decision Input Requested: -EQ with Characters

BoundedSpace — Tue, 23 Sep 2008 19:03:05 GMT

Please, please fix this.

Better to break a few scripts that depend on what is clearly a bug than have stange behaviour that all users might well be surprised by and will have to remember as an oddity.

re: Decision Input Requested: -EQ with Characters

KenH — Tue, 23 Sep 2008 19:25:33 GMT

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

re: Decision Input Requested: -EQ with Characters

slipsec — Tue, 23 Sep 2008 20:47:27 GMT

Fix it! IMO one of the biggest problems with MS is the reluctance to fix _BUGS_ because they might break backwards compatibility. If you want to work backwards, use the legacy product, or fix your scripts/apps to work with the newer *FIXED* edition. Supporting old scripts is great, but at the price of preserving bugs? I'm not even sure how this can be a question.

re: Decision Input Requested: -EQ with Characters

mevi — Tue, 23 Sep 2008 21:19:54 GMT

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.

re: Decision Input Requested: -EQ with Characters

abqbill — Tue, 23 Sep 2008 21:33:24 GMT

Hi Jeffrey,

Greetings from Albuquerque (we met at the IT Pro Townhall meeting dinner in April 2007). I want to echo Jason Fossen's comments, above. My opinion is that the v1 behavior is counterintuitive to the majority of your target audience. My experience is that non-developers tend to get frustrated more easily with these kinds of problems.

re: Decision Input Requested: -EQ with Characters

Guy Ellis — Tue, 23 Sep 2008 22:39:08 GMT

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.

re: Decision Input Requested: -EQ with Characters

Joshua — Tue, 23 Sep 2008 23:26:40 GMT

It might break existing scripts but fix it anyway.

re: Decision Input Requested: -EQ with Characters

Darren Gosbell — Wed, 24 Sep 2008 00:16:00 GMT

Fix it.

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

re: Decision Input Requested: -EQ with Characters

Eric Lee — Wed, 24 Sep 2008 01:18:15 GMT

Like most people, I vote for fixing it. Backwards compatibility is nice in the short-term but it's pure evil in the long-term. There's no reason why everyone should have to live with this bug *forever*. Just take the hit now and fix it.

Of course, I'm not the one who's going to have broken scripts, so take that for what it's worth. :-)

re: Decision Input Requested: -EQ with Characters

Bruno Gomes — Wed, 24 Sep 2008 02:21:47 GMT

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.

re: Decision Input Requested: -EQ with Characters

David Moisan — Wed, 24 Sep 2008 03:17:29 GMT

I say "fix it!" People are using the example "A" -eq "a", but we know very well that's not how the comparison will happen in real life.

It'll be more like:

$fileA -eq $FileB

where $fileA is = "rundll.exe" and $FileB is

"RUNDLL.EXE".

And *that* will be confusing, the sort of thing that Linux advocates will crow about for years.

re: Decision Input Requested: -EQ with Characters

Cullen — Wed, 24 Sep 2008 03:25:45 GMT

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.

re: Decision Input Requested: -EQ with Characters

Hal Rottenberg — Wed, 24 Sep 2008 05:07:53 GMT

Dang...a ton of comments on this post.

I fall on the "[char]'a' -ieq 'A'

This should eval to TRUE since it's what 90% of administrative scripters (the main target audience) would expect." side of the fence.

Fix it.

re: Decision Input Requested: -EQ with Characters

Keith Hill — Wed, 24 Sep 2008 09:31:18 GMT

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.

re: Decision Input Requested: -EQ with Characters

Cedric — Wed, 24 Sep 2008 11:16:06 GMT

Yes, Fix it...

With a "big" warning in release notes ;). It's most important to fix bug that to be compatible with old script that take advantage of a bug. I think the most important is that the "work around" found by some of us (if any) still works...

Regards!

re: Decision Input Requested: -EQ with Characters

Bruno Gomes — Wed, 24 Sep 2008 14:18:18 GMT

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.

re: Decision Input Requested: -EQ with Characters

Cash Foley — Wed, 24 Sep 2008 19:03:58 GMT

Fix the bug. If it's not too awkward, provide a switch that can be configured or set in a script for backwards compatibility.

re: Decision Input Requested: -EQ with Characters

Cash Foley — Wed, 24 Sep 2008 19:12:49 GMT

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

re: Decision Input Requested: -EQ with Characters

Jay Bazuzi — Wed, 24 Sep 2008 20:20:13 GMT

Please fix it! The sooner the better.

You're worried about the number of scripts out there today that could be broken, but think how many more scripts there will be in 10 years. Save the future from the present!

re: Decision Input Requested: -EQ with Characters

Staffan Gustafsson — Thu, 25 Sep 2008 00:11:38 GMT

Fix it.

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

re: Decision Input Requested: -EQ with Characters

Ken Taylor — Thu, 25 Sep 2008 01:10:28 GMT

I vote fix it. It's still pretty early in the grand scheme of things.

re: Decision Input Requested: -EQ with Characters

Stefan Falk — Fri, 26 Sep 2008 11:30:43 GMT

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

re: Decision Input Requested: -EQ with Characters

Hans Meiser — Fri, 26 Sep 2008 17:01:35 GMT

Fix this bug asap and change the file extension from ps1 to ps2. It is much easier to change the file extension than adding "reqires version 2" on each and every new script.

re: Decision Input Requested: -EQ with Characters

karl prosser — Sat, 27 Sep 2008 00:37:31 GMT

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.

re: Decision Input Requested: -EQ with Characters

Karl — Sun, 28 Sep 2008 20:20:32 GMT

[char]'a' -ieq 'A' should get fixed even if there are body of scripts coded to the old behavior.

You can soften the blow with compiler modes or 'depricated' warnings.

re: Decision Input Requested: -EQ with Characters

Poshoholic — Mon, 29 Sep 2008 04:48:04 GMT

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

re: Decision Input Requested: -EQ with Characters

Poshoholic — Mon, 29 Sep 2008 16:53:30 GMT

Sorry, one typo in my last comment. The # this should be False comment shouldn't be there. Copy/paste bug. :P

Anyhow, the point is the same regardless. -contains needs the same attention for [char[]] as -eq does for [char].

re: Decision Input Requested: -EQ with Characters

dreeschkind — Mon, 29 Sep 2008 20:19:27 GMT

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

re: Decision Input Requested: -EQ with Characters

Stuart Henderson — Tue, 30 Sep 2008 01:50:15 GMT

Definitely fix it. Jaykuls 'switch' example provides a 100% convincing argument as I see it.

If you don't fix it now more scripts will be written, thus increasing the surface area for pain when the issue resurfaces in the future.

Just my $00.02

Stuart

re: Decision Input Requested: -EQ with Characters

Maximilian Hänel — Tue, 30 Sep 2008 10:38:21 GMT

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!

re: Decision Input Requested: -EQ with Characters

bschneid — Tue, 30 Sep 2008 21:08:03 GMT

IMHO, this is a bug and should be addressed. If types are defined then you should get what you ask for:

[char]'A' -ceq [int]65 [evaluates True](Valid)

[char]'a' -ceq [int]97 [evaluates True](Valid)

[char]'A' -ieq [char]'a' [evaluates False](Valid: 65 != 97)

I agree with Bruno Gomes about if a=b then b=a. Which this example shows does not work here:

[string]'a' -ieq [char]'A' [evaluates True]

[char]'A' -ieq [string]'a' [evaluates False]

However, both should evaluate as False as String and Char types should not be equal. And for that matter, the following should evaluate as false:

[string]'a' -eq [char]'a' [evaluates True]

[char]'a' -eq [string]'a' [evaluates True]

If a script doesn't define types, then this is all that is required:

'a' -ceq 'A' [evaluates False]

'a' -ieq 'A' [evaluates True]

re: Decision Input Requested: -EQ with Characters

Mark Ross — Tue, 07 Oct 2008 21:17:04 GMT

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.

re: Decision Input Requested: -EQ with Characters

Rainer Böhme — Fri, 17 Oct 2008 00:01:40 GMT

Fix it!

I'm not sure if any user at all considered this as a feature and used it.

If you're still worried about backward compatibility then put in an option to switch on a "1.0 compatibility mode", as a command line option or environment variable.

This might be even more useful if there are other compatibility breaking changes in 2.0.

re: Decision Input Requested: -EQ with Characters

Anders Haahr — Sun, 19 Oct 2008 00:23:00 GMT

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.

re: Decision Input Requested: -EQ with Characters

Stephen Mills — Tue, 21 Oct 2008 23:17:12 GMT

I say fix it as well. Some people say that a char should never be the same as a string, but from an admin point of view that makes no sense. How about the example:

[char]'a' -ieq (([string]'A')[0])

False

(([string]'A')[0]).gettype()

Name: Char

A string can be referenced by the array operator, which in turn returns a Char. In this case I did not explicitly cast it as a Char, but still got a Char result from a String source. So it doesn't make sense to me to say they can't be compared, especially when a char appears to be an element in a string.

re: Decision Input Requested: -EQ with Characters

Fancyf — Tue, 28 Oct 2008 12:04:41 GMT

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