We are struggling with whether or not to make a change in our comparison operators and would like feedback from the community.<\/p>\n
Here is the documentation about comparision operators: <\/p>\n
\nAll 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”.<\/p>\n<\/blockquote>\nHere are examples of the current -EQ semantics:<\/p>\n
PS> “a” -eq “A”
True
PS> [char]’a’ -eq ‘a’
True
PS> 2 -eq 2
True<\/p>\nNotice that -EQ works with Strings, Chars, and INTs (and lots of other things). <\/p>\n
Now for the headache: <\/p>\n
PS> [char]’a’ -eq ‘A’
False
<\/strong>PS> [char]’a’ -ieq ‘A’
False<\/strong><\/p>\n<Update: Notice that you get FALSE whether you use -eq (EQUALS) or -ieq (CASE INSENSITIVE EQUALS) ><\/p>\n
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:<\/p>\n
\n
- Whenever you fix a bug, you run the risk of breaking a script.<\/li>\n
- We are committed to making V2 useful and compatible with V1.<\/li>\n<\/ol>\n
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?<\/p>\n
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. <\/p>\n
Please opine.<\/p>\n
<UPDATE: BTW 10,000 apologizes for this situation in the first place. I should have started with that.><\/p>\n
Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at: http:\/\/blogs.msdn.com\/PowerShell<\/a>
Visit the Windows PowerShell ScriptCenter at: http:\/\/www.microsoft.com\/technet\/scriptcenter\/hubs\/msh.mspx<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"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”. […]<\/p>\n","protected":false},"author":600,"featured_media":13641,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-5461","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-powershell"],"acf":[],"blog_post_summary":"
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”. […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts\/5461","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/users\/600"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/comments?post=5461"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts\/5461\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/media\/13641"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/media?parent=5461"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/categories?post=5461"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/tags?post=5461"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}