Repository navigation
Should namespaces should be case perserving/Case-Insensitive? #706
Description
Activity
What do you mean by namespaces here? (The word is pretty overloaded)
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.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.
Reacted by Joel Bennett and Michael KlementAdding 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.
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.
Joey Aiello (@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
fooat the command-line, in Windows it's going to run the alias, not foo.exeReacted by Keith Hillcase-insensitive. I should be able to designate when I need case-sensitive.
Reacted by Ben Creasy4 remaining items
- removed this from the milestone
on May 22, 2017 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 (
#regionor comment-based help, for instance), but for the sake of this disucssion, I think that's irrelevant.
- There are exceptions (
- 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)
- One option which is an exact match
- Namespace: Apple; Input: Apple
- One match which doesn't match the given case
- Namespace: Apple; Input: apple
- Multiple matches where one matches the given case
- Namespaces: Apple, apple; Input: Apple
- 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-ItemandRename-Itemcan't change a file's case in placeClarifying 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.
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")?@PowerShell/powershell-committee reviewed this and modules paths and names should be case-insensitive #3573
Discuss. (I don't know what the right answer is)