Decision Input Requested: -EQ with Characters

Decision Input Requested: -EQ with Characters

  • Comments 61

We are struggling with whether or not to make a change in our comparison operators and would like feedback from the community.

Here is the documentation about comparision operators: 

 All comparison operators are case-insensitive by default. To make a comparison operator
 case-sensitive, precede the operator name with a "c". For example, the case-sensitive
 version of "-eq" is "-ceq". To make the case-insensitivity explicit, precede the operator
 with an "i", for example, the explicitly case-insensitive version of "-eq" is "ieq".

Here are examples of the current -EQ semantics:

PS> "a" -eq "A"
True
PS> [char]'a' -eq 'a'
True
PS> 2 -eq 2
True

Notice that -EQ works with Strings, Chars, and INTs (and lots of other things). 

Now for the headache: 

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

What is happening here is that CHARs are being treated like INTs and not like STRINGs.  In our bug triage, we the feeling was that this was clearly a bug and should be fixed but someone pointed out that this if a script made use of these semantics, fixing the bug would break that script.  There are 2 things to say about that:

  1. Whenever you fix a bug, you run the risk of breaking a script.
  2. We are committed to making V2 useful and compatible with V1.

So you see the rub.  We'd like your help and input on this decision.  I'm fine getting feedback on the "general principles" of the issue - understanding how you think about these issues is very helpful to us.  That said, I'm also keenly interested in comments about the specifics of this problem. If we make THIS change, do you think it will break scripts?  If so, should we fix this anyway or not?

We struggled with this decision and had lots of back and forth on this and could go either way.  In the end, we decided that a key stackholder wasn't in the room:  YOU. 

Please opine.

<UPDATE:  BTW 10,000 apologizes for this situation in the first place.  I should have started with that.>

Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx

Leave a Comment
  • Please add 1 and 2 and type the answer here:
  • Post
  • 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 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.  

  • 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.

  • Definitely a bug and should be fixed.

  • 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.

  • [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!

  • 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.

  • 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.

  • 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.

  • 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.

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

  • 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.

  • 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.  

  • 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.

  • 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.

Page 2 of 5 (61 items) 12345