![\"Photo](\"https:\/\/msdnshared.blob.core.windows.net\/media\/TNBlogsFS\/prod.evol.blogs.technet.com\/CommunityServer.Blogs.Components.WeblogFiles\/00\/00\/00\/76\/18\/MikeRobbins.PNG\" "\\"Photo")
<\/a><\/p>\nMike F Robbins is a Microsoft MVP for Windows PowerShell and a SAPIEN Technologies MVP. He is a co-author of Windows PowerShell TFM 4th<\/sup> Edition<\/i>, and is a contributing author of a chapter in the PowerShell Deep Dives<\/i> book. Mike has written guest blog posts for the Hey, Scripting Guy! Blog, PowerShell Magazine, and PowerShell.org. He is the winner of the advanced category in the 2013 PowerShell Scripting Games. Mike is also the leader and co-founder of the Mississippi PowerShell User Group<\/a>. He blogs at mikefrobbins.com<\/a> and can be found on twitter @mikefrobbins<\/a>.<\/p>\n A few months ago I wrote a blog post called Some Cases of Unexpected Case Sensitivity in PowerShell<\/a>, and I thought I would expand on that topic a bit here as a sequel to that original post.<\/p>\n Everything is case insensitive in PowerShell, right? Well, that’s what we’re normally taught, but it’s actually not quite that simple. The answer to whether PowerShell is case sensitive is, “It depends.” In general, PowerShell is not case sensitive, but there are a number of caveats to case sensitivity, some of which are intentional, and some that are unexpected.<\/p>\n By default, the comparison operators that you’ll commonly see used with PowerShell are case insensitive. These include:<\/p>\n Each of these comparison operators have a corresponding case-sensitive version:<\/p>\n Each of these operators also has a case-insensitive version that begins with an i<\/b> instead of a c<\/b>. These versions are explicitly case insensitive, although you’ll rarely (if ever) see them used because their behavior is the same as where i<\/b> or c<\/b> is not specified.<\/p>\n Here is an example of using these operators:<\/p>\n PS C:\\> 'PowerShell' -eq 'powershell'<\/p>\n True<\/p>\n PS C:\\> 'PowerShell' -ceq 'powershell'<\/p>\n False<\/p>\n PS C:\\> 'PowerShell' -ieq 'powershell'<\/p>\n True<\/p>\n PS C:\\><\/p>\n To learn more about comparison operators, see the about_Comparison_Operators Help topic in PowerShell or view the online version: about_Comparison_Operators<\/a>.<\/p>\n All of the alphabet-based escape characters are case sensitive:<\/p>\n<\/div>\n The special meaning of these characters doesn’t occur when an upper-case character is specified, for example:<\/p>\n PS C:\\> "Hey, Scripting `n Guy! Blog"<\/p>\n Hey, Scripting<\/p>\n Guy! Blog<\/p>\n PS C:\\> "Hey, Scripting `N Guy! Blog"<\/p>\n Hey, Scripting N Guy! Blog<\/p>\n PS C:\\><\/p>\n To learn more about escape characters, see the about_Escape_Characters Help topic in PowerShell or view the online version: about_Escape_Characters<\/a>.<\/b><\/p>\n Regions were introduced in Windows PowerShell 3.0. Specifying the #region<\/b> or #endregion<\/b> tags in anything other than lower-case letters breaks the ability to collapse that portion of the code.<\/p>\n When you’re using PowerShell to access information from a technology that’s outside of PowerShell, such as from Active Directory with ADSI, the rules for case sensitivity in PowerShell no longer apply. An example is shown in the following function. If the case for samaccountname<\/b> is changed inside of pscustomobject<\/b>, the samaccountname<\/b> will not be returned.<\/p>\n #Requires -Version 3.0<\/p>\n function Get-MrADUser { <\/p>\n [CmdletBinding()]<\/p>\n param(<\/p>\n [Parameter(Mandatory,<\/p>\n ValueFromPipeline,<\/p>\n ValueFromPipelineByPropertyName)]<\/p>\n [String[]]$UserName<\/p>\n ) <\/p>\n PROCESS { <\/p>\n foreach ($user in $UserName){ <\/p>\n $Search = [adsisearcher]"(&(objectCategory=person)(objectClass=user)(samaccountname=$user))"<\/p>\n foreach ($user in $($Search.FindAll())){ <\/p>\n $stringSID = (New-Object -TypeName System.Security.Principal.SecurityIdentifier($($user.Properties.objectsid),0)).Value<\/p>\n $objectGUID = [System.Guid]$($user.Properties.objectguid)<\/p>\n [pscustomobject]@{<\/p>\n DistinguishedName = $($user.Properties.distinguishedname)<\/p>\n Enabled = (-not($($user.GetDirectoryEntry().InvokeGet('AccountDisabled'))))<\/p>\n GivenName = $($user.Properties.givenname)<\/p>\n Name = $($user.Properties.name)<\/p>\n ObjectClass = $($user.Properties.objectclass)[-1]<\/p>\n ObjectGUID = $objectGUID<\/p>\n SamAccountName = $($user.Properties.samaccountname)<\/p>\n SID = $stringSID<\/p>\n Surname = $($user.Properties.sn)<\/p>\n UserPrincipalName = $($user.Properties.userprincipalname)<\/p>\n }<\/p>\n }<\/p>\n }<\/p>\n }<\/p>\n }<\/p>\n Some cmdlets have parameters to control case sensitivity. One example is the Sort-Object<\/b> cmdlet, which has a CaseSensitive<\/b> parameter. Specifying this parameter when using Sort-Object<\/b> indicates that the sort should be case sensitive. By default, sorting with Sort-Object<\/b> is case insensitive. Here are some examples:<\/p>\n PS C:\\> 'PowerShell', 'powershell', 'POWERSHELL' | Sort-Object<\/p>\n POWERSHELL<\/p>\n powershell<\/p>\n PowerShell<\/p>\n PS C:\\> 'PowerShell', 'powershell', 'POWERSHELL' | Sort-Object -CaseSensitive<\/p>\n powershell<\/p>\n PowerShell<\/p>\n POWERSHELL<\/p>\n PS C:\\><\/p>\n Case-insensitive switch statements are not supported in PowerShell workflows. For more detailed information about this topic and to learn how to work around this, see the following Hey, Scripting Guy! Blog post: PowerShell Workflows: Restrictions<\/a>.<\/p>\n Hash tables are case insensitive by default. Notice that I can’t add ComputerName<\/b> and computername<\/b> to the hash table in the following example because, by default, the keys are the same:<\/p>\n PS C:\\> $hashtable = @{}<\/p>\n PS C:\\> $hashtable.Add('ComputerName', 'PC01')<\/p>\n PS C:\\> $hashtable.Add('computername', 'pc01')<\/p>\n Exception calling "Add" with "2" argument(s): "Item has already been added. Key in dictionary: 'ComputerName' Key<\/p>\n being added: 'computername'"<\/p>\n At line:1 char:1<\/p>\n + $hashtable.Add('computername', 'pc01')<\/p>\n + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<\/p>\n + CategoryInfo : NotSpecified: (:) [], MethodInvocationException<\/p>\n + FullyQualifiedErrorId : ArgumentException<\/p>\n PS C:\\><\/p>\n A special case-sensitive hash table can be created though. Notice in the following example, I can add the two keys that failed in the previous example:<\/p>\n PS C:\\> $hashtable = New-Object -TypeName System.Collections.Hashtable<\/p>\n PS C:\\> $hashtable.Add('ComputerName', 'PC01')<\/p>\n PS C:\\> $hashtable.Add('computername', 'pc01')<\/p>\n PS C:\\> $hashtable<\/p>\n Name Value<\/p>\n —- —–<\/p>\n ComputerName PC01<\/p>\n computername pc01<\/p>\n PS C:\\><\/p>\n JSON is case sensitive, but the custom objects that are created when using the ConvertFrom-Json<\/b> cmdlet are case insensitive. For more detailed information abouit JSON, see this Hey, Scripting Guy! Blog post: JSON Is the New XML<\/a>.<\/p>\n As you can see in the following example, methods such as contains<\/b> and replace<\/b> are case sensitive, whereas the contains<\/b> and replace<\/b> operators are not case sensitive.<\/p>\n PS C:\\> $Features = 'SQLENGINE', 'SSMS', 'ADV_SSMS'<\/p>\n PS C:\\> $Features.Contains('SQLENGINE')<\/p>\n True<\/p>\n PS C:\\> $Features -contains 'SQLENGINE'<\/p>\n True<\/p>\n PS C:\\> $Features.Contains('SQLEngine')<\/p>\n False<\/p>\n PS C:\\> $Features -contains 'SQLEngine'<\/p>\n True<\/p>\n PS C:\\><\/p>\n Do you think that you’ll outsmart the case-sensitivity issues in PowerShell by using the ToUpper<\/b> or ToLower<\/b> method to convert strings to a specific case before performing comparison operations on them? Not so fast. You could be creating a different problem—especially if you’re potentially working with other cultures. If you’re thinking about going this route, consider reading my blog post Using Pester to Test PowerShell Code in Other Cultures<\/a>.<\/p>\n ~Mike<\/p>\n Thanks for clarifying a somewhat confusing issue for us, Mike.<\/p>\n I invite you to follow me on Twitter<\/a> and Facebook<\/a>. If you have any questions, send email to me at scripter@microsoft.com<\/a>, or post your questions on the Official Scripting Guys Forum<\/a>. See you tomorrow. Until then, peace.<\/p>\n Ed Wilson, Microsoft Scripting Guy<\/b> <\/p>\n","protected":false},"excerpt":{"rendered":" Summary: PowerShell MVP, Mike F Robbins, discusses case sensitivity in Windows PowerShell. Microsoft Scripting Guy, Ed Wilson, is here. Welcome back guest blogger, Mike Robbins. Mike F Robbins is a Microsoft MVP for Windows PowerShell and a SAPIEN Technologies MVP. He is a co-author of Windows PowerShell TFM 4th Edition, and is a contributing author […]<\/p>\n","protected":false},"author":597,"featured_media":87096,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[56,344,3,4,336,134,61,45],"class_list":["post-75851","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-scripting","tag-guest-blogger","tag-mike-f-robbins","tag-scripting-guy","tag-scripting-techniques","tag-strings","tag-troubleshooting","tag-weekend-scripter","tag-windows-powershell"],"acf":[],"blog_post_summary":" Summary: PowerShell MVP, Mike F Robbins, discusses case sensitivity in Windows PowerShell. Microsoft Scripting Guy, Ed Wilson, is here. Welcome back guest blogger, Mike Robbins. Mike F Robbins is a Microsoft MVP for Windows PowerShell and a SAPIEN Technologies MVP. He is a co-author of Windows PowerShell TFM 4th Edition, and is a contributing author […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/75851","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/users\/597"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/comments?post=75851"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/75851\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media\/87096"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media?parent=75851"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/categories?post=75851"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/tags?post=75851"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Operators<\/h3>\n
\n
\n
Escape characters<\/h3>\n
\n
Region and EndRegion tags<\/h3>\n
External technologies<\/h3>\n
Cmdlets<\/h3>\n
Switch statements<\/h3>\n
Hash tables<\/h3>\n
JSON<\/h3>\n
Methods<\/h3>\n