Powershell: Should namespaces should be case perserving/Case-Insensitive?

[jpsnover]

Discuss. (I don't know what the right answer is)

[vors]

What do you mean by namespaces here? (The word is pretty overloaded)

[jpsnover]

In PS, "namespaces" refer to everything exposed by a PSProvider - e.g. Get-PSDrive
So clearly variables,aliases and functions need to be case-insensitive.
I'm leaning towards thinking that ENV should be case-insensitive as well.
I'm just not clear at all about how we should handle files/directories.

[andschwa]

I do not think that the filesystem provider can be case insensitive on a case sensitive filesystem, as it would make it impossible to use correctly. As for environment variables, this behavior could lead to very unexpected incompatibility with external processes.

However, I think that PowerShell's tab completion could and should certainly handle smart casing.

[joeyaiello]

Adding this to the list of usability conversations we need to have. There's a ton of stuff re: case sensitivity that we still have to address.

[joeyaiello]

Multiple cases which need to be solved for namespaces, provider cmdlets (e.g. New-Item, Test-Path), etc.

• One option which is an exact match
• One match which doesn't match the given case
• Multiple matches where one matches the given case
• Multiple matches where none match the given case

We should start filling out this matrix for all possible cases where they apply.

[Jaykul]

@joeyaiello what about command names?

So if I have an alias "FOO" and a script function "Foo" and a "foo.exe" in my path ... if I type foo at the command-line, in Windows it's going to run the alias, not foo.exe

[Zsoldier]

case-insensitive. I should be able to designate when I need case-sensitive.

[joeyaiello]

As stated in #3573, right now Remove-Module is case-insensitive, and Import-Module is case-sensitive.

I still think my original principles apply to this scenario.

[joeyaiello]

Long discussion about case sensitivity in general by @PowerShell/powershell-committee today.

Some starting principles:

• C# (and by extension, .NET) is fully case sensitive (types, variables, methods, etc.)
• Internally, PowerShell is case-insensitive (PS variables, functions, cmdlets)
  
  
  
  • There are exceptions (#region or comment-based help, for instance), but for the sake of this disucssion, I think that's irrelevant.
  
  
• For most cases, filesystems are case-sensisitive (even on Windows, it's tricky, but NTFS can have two files with the same case).
• On non-Windows platforms, environment variables are case-sensitive. PowerShell already respects the platform behavior here.
• Tab completion is interactive where we allow all kinds of things that aren't possible with scripted behavior (which has to be deterministic)

As I linked above, there's 4 different cases that have to be solved for (I'm going to use "Namespace" as the stand-in term for all the things being discussed in this thread)

1. One option which is an exact match
   
   
   
   • Namespace: Apple; Input: Apple
   
   
2. One match which doesn't match the given case
   
   
   
   • Namespace: Apple; Input: apple
   
   
3. Multiple matches where one matches the given case
   
   
   
   • Namespaces: Apple, apple; Input: Apple
   
   
4. Multiple matches where none match the given case
   
   
   
   • Namespaces: Apple, apple; Input: aPPLE
   
   

Everyone in the room agreed that 1 and 3 should always match the exact match. From there, we agreed that 2 and 4 shouldn't "do something random" by calling the incorrect match.

However, we also agreed that tab-completing in a case-insensitive way is highly desirable so as to correct typing errors. We already do this for .NET namepsaces (e.g. [environme<tab> completes to [System.Environment]). (It should probably go without saying, but this would be implemented as a PSReadline feature and should be exposed as a configurable option.)

Bug to file that could make this all annoying: Move-Item and Rename-Itemcan't change a file's case in place

[joeyaiello]

Clarifying question to @PowerShell/powershell-committee based on #1621. The statement "internally, PowerShell is case-insensitive" breaks down when you look at modules. I've elaborated in that issue.

[iSazonov]

Is there _really_ namespaces differing only by case? In C#?
If so can we have a way to resolve such conflict in PowerShell (as for modules - "different path")?

[SteveL-MSFT]

@PowerShell/powershell-committee reviewed this and modules paths and names should be case-insensitive https://github.com/PowerShell/PowerShell/issues/3573