Repository navigation
$env:PATH casing on Linux is not consistent with $env:Path on Windows #3571
Description
Steps to reproduce
Expected behavior
You've changed casing for $env:PSModulePath on Linux to be consistent with Windows. I would expect the same for $env:Path. (or any other environmental variable that would exist on both platforms)
Actual behavior
$env:PATH on Linux and $env:Path on Windows
Environment data
PS /home/aleksandar> $PSVersionTable
Name Value
---- -----
PSVersion 6.0.0-alpha
PSEdition Core
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 3.0.0.0
GitCommitId v6.0.0-alpha.18
CLRVersion
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
Activity
jeffbi commentedon Apr 17, 2017
Case-sensitivity issues rise again!
$PATHand$Pathare two different environment variables on Unix platforms. On Windows they are not.iSazonov commentedon Apr 17, 2017
It seems as bad UX. On Unix too: why use Path,PAth,PaTh,PatH for in the same time?!
Related Issue #3573 about module names: MoDuLeNaMe?!
/cc Keith Hill (@rkeithhill)
We should save PowerShell Engine on both platforms as case-insensitive but FileSystemProvider on Linux case-sensitive.
mklement0 commentedon Apr 17, 2017
To add to jeffbi's comment:
$env:PSModulePathis under PowerShell's control,$env:Path(Windows) /$env:PATH(Unix) is not.It's unfortunate that these system-fundamental environment variables are defined differently across platforms (and that the case-sensitivity of accessing them varies), but I fear it's something we'll have to live with.
The workaround is to use
$env:PATH(all-uppercase) consistently on all platforms, which will work on Windows too (due to its case-insensitive variable access).iSazonov commentedon Apr 17, 2017
The workaround is a working.
Only with each passing day I become more and more fear that consumers will curse us, if even two environment variables follow different rules!
For better UX we should follow simple and common rule, ex:
joeyaiello commentedon Apr 17, 2017
Total agreement with Michael Klement (@mklement0) on this one.
Ilya (@iSazonov) what do you mean by "externally" vs "internally"
iSazonov commentedon Apr 17, 2017
Sorry, "internally" - I mean PowerShell language, "externally" - file systems, environment variables, native commands and so on.
jeffbi commentedon Apr 17, 2017
File system case-sensitivity should be filesystem-specific, not OS-specific. Windows can be case-sensitive on NTFS volumes with the right Registry tweak, and if it can read/write Linux ext file systems, those are case-sensitive.
Even on Linux, FAT volumes are case-insensitive.
The HFS+ file system on OS X is not case-sensitive
mklement0 commentedon Apr 17, 2017
Good points, jeffbi; just to elaborate a little (do tell me if I'm wrong):
NTFS:
NTFS is intrinsically case-sensitive, whereas the Windows API is not (by default).
Therefore, any software that bypasses the Windows API can gain case-sensitive access, irrespective of the system configuration (such as the registry setting mentioned below) - this is what WSL, the Windows Subsystem for Linux that
bashon Window is based on, does.The registry tweak you mention -
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel, valueobCaseInsensitive- is the prerequisite for enabling case-sensitivity opt-in by the Windows API methods via theFILE_FLAG_POSIX_SEMANTICSflag.HFS+
newfs_hfs -s ...).jeffbi commentedon Apr 18, 2017
Michael Klement (@mklement0) I believe your points are correct. A couple of additional notes:
Fredandfred, but when opening either Windows will always actually open only one of them---it seems to favor ones with upper-case letters in the name.SteveL-MSFT commentedon Apr 21, 2017
Going back to the original topic, we were able to change PSModulePath as that's an env var we create, but Path and PATH already exists in their respective operating systems. We could have tab-complete always make Path uppercase as Windows will happily treat $env:PATH as $env:Path so at least script authors have a consistent variable for cross platform scripts, but it's not clear to me how many cross platform scripts will make use of PATH as absolute file paths are inherently different on different operating systems.
20 remaining items
TSlivede commentedon May 24, 2017
Steve Lee (@SteveL-MSFT)
Just an additional thought on
$interop:PATH:Could that variable have type
System.Collections.Generic.List`1[System.IO.DirectoryInfo]?This way it would be easy to add things to the path, and one doesn't need to worry about using
:or;as a separator.Instead one could just do:
$interop:PATH.Add('/some/path/')or
$interop:PATH += '/some/path/'(The format of the path string gets even validated!)
The same applies to
$env:PSModulePath-- A corresponding$interop:PSModulePathwith type List would be really nice.joeyaiello commentedon May 30, 2017
Just to add the trackback, we're looking at PowerShell/PowerShell-RFC#92 (and I need to add some details there that explain our current thoughts on this issue).
SteveL-MSFT commentedon Aug 31, 2017
I'm going to defer this work to 6.1.0 since PATH and Path are different and aren't really cross platform compatible
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 23, 2023
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.