You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Should namespaces should be case perserving/Case-Insensitive? #706
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.
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
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)
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-Item and Rename-Item can't change a file's case in place
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.
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")?
Activity
vors commentedon Mar 20, 2016
What do you mean by namespaces here? (The word is pretty overloaded)
jpsnover commentedon Mar 20, 2016
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.
andyleejordan commentedon Mar 21, 2016
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 commentedon Mar 24, 2016
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 commentedon Jun 13, 2016
Multiple cases which need to be solved for namespaces, provider cmdlets (e.g.
New-Item,Test-Path), etc.We should start filling out this matrix for all possible cases where they apply.
Jaykul commentedon Aug 6, 2016
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.exeZsoldier commentedon Sep 1, 2016
case-insensitive. I should be able to designate when I need case-sensitive.
4 remaining items
joeyaiello commentedon Aug 3, 2017
Long discussion about case sensitivity in general by @PowerShell/powershell-committee today.
Some starting principles:
#regionor comment-based help, for instance), but for the sake of this disucssion, I think that's irrelevant.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)
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 placejoeyaiello commentedon Aug 3, 2017
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 commentedon Aug 3, 2017
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 commentedon Sep 6, 2017
@PowerShell/powershell-committee reviewed this and modules paths and names should be case-insensitive #3573