case sensitivity of Path environment variable on windows
#446
Comments
|
I would say it is a bug on both sides. emacs should use |
compnerd
added a commit
to compnerd/swift-tools-support-core
that referenced
this issue
Nov 25, 2023
Windows is case insensitive for the environment control block, which we did not honour. This causes issues when Swift is used with programs which are incorrectly cased (e.g. emacs). Introduce an explicit wrapper type for Windows to make the lookup case insensitive, canonicalising the name to lowercase. This allows us to treat `Path` and `PATH` identically (along with any other environment variable and case matching) which respects the Windows behaviour. Additionally, migrate away from the POSIX variants which do not handle the case properly to the Windows version which does. Fixes: swiftlang#446
|
@cobbal not sure if this actually fixes the emacs issue, but is definitely a step in the right direction. Unfortunately, we do need to audit the rest of the stack to handle this :(. |
compnerd
added a commit
to compnerd/swift-tools-support-core
that referenced
this issue
Nov 26, 2023
Windows is case insensitive for the environment control block, which we did not honour. This causes issues when Swift is used with programs which are incorrectly cased (e.g. emacs). Introduce an explicit wrapper type for Windows to make the lookup case insensitive, canonicalising the name to lowercase. This allows us to treat `Path` and `PATH` identically (along with any other environment variable and case matching) which respects the Windows behaviour. Additionally, migrate away from the POSIX variants which do not handle the case properly to the Windows version which does. Fixes: swiftlang#446
compnerd
added a commit
to compnerd/swift-tools-support-core
that referenced
this issue
Nov 27, 2023
Windows is case insensitive for the environment control block, which we did not honour. This causes issues when Swift is used with programs which are incorrectly cased (e.g. emacs). Introduce an explicit wrapper type for Windows to make the lookup case insensitive, canonicalising the name to lowercase. This allows us to treat `Path` and `PATH` identically (along with any other environment variable and case matching) which respects the Windows behaviour. Additionally, migrate away from the POSIX variants which do not handle the case properly to the Windows version which does. Fixes: swiftlang#446
compnerd
added a commit
to compnerd/swift-tools-support-core
that referenced
this issue
Nov 27, 2023
Windows is case insensitive for the environment control block, which we did not honour. This causes issues when Swift is used with programs which are incorrectly cased (e.g. emacs). Introduce an explicit wrapper type for Windows to make the lookup case insensitive, canonicalising the name to lowercase. This allows us to treat `Path` and `PATH` identically (along with any other environment variable and case matching) which respects the Windows behaviour. Additionally, migrate away from the POSIX variants which do not handle the case properly to the Windows version which does. Fixes: swiftlang#446
compnerd
added a commit
to compnerd/swift-tools-support-core
that referenced
this issue
Dec 8, 2023
Windows is case insensitive for the environment control block, which we did not honour. This causes issues when Swift is used with programs which are incorrectly cased (e.g. emacs). Introduce an explicit wrapper type for Windows to make the lookup case insensitive, canonicalising the name to lowercase. This allows us to treat `Path` and `PATH` identically (along with any other environment variable and case matching) which respects the Windows behaviour. Additionally, migrate away from the POSIX variants which do not handle the case properly to the Windows version which does. Fixes: swiftlang#446
compnerd
added a commit
to compnerd/swift-tools-support-core
that referenced
this issue
Dec 9, 2023
Windows is case insensitive for the environment control block, which we did not honour. This causes issues when Swift is used with programs which are incorrectly cased (e.g. emacs). Introduce an explicit wrapper type for Windows to make the lookup case insensitive, canonicalising the name to lowercase. This allows us to treat `Path` and `PATH` identically (along with any other environment variable and case matching) which respects the Windows behaviour. Additionally, migrate away from the POSIX variants which do not handle the case properly to the Windows version which does. Fixes: swiftlang#446
compnerd
added a commit
to compnerd/swift-tools-support-core
that referenced
this issue
Dec 9, 2023
Windows is case insensitive for the environment control block, which we did not honour. This causes issues when Swift is used with programs which are incorrectly cased (e.g. emacs). Introduce an explicit wrapper type for Windows to make the lookup case insensitive, canonicalising the name to lowercase. This allows us to treat `Path` and `PATH` identically (along with any other environment variable and case matching) which respects the Windows behaviour. Additionally, migrate away from the POSIX variants which do not handle the case properly to the Windows version which does. Fixes: swiftlang#446
compnerd
added a commit
to compnerd/swift-tools-support-core
that referenced
this issue
Dec 9, 2023
Windows is case insensitive for the environment control block, which we did not honour. This causes issues when Swift is used with programs which are incorrectly cased (e.g. emacs). Introduce an explicit wrapper type for Windows to make the lookup case insensitive, canonicalising the name to lowercase. This allows us to treat `Path` and `PATH` identically (along with any other environment variable and case matching) which respects the Windows behaviour. Additionally, migrate away from the POSIX variants which do not handle the case properly to the Windows version which does. Fixes: swiftlang#446
compnerd
added a commit
to compnerd/swift-tools-support-core
that referenced
this issue
Dec 11, 2023
Windows is case insensitive for the environment control block, which we did not honour. This causes issues when Swift is used with programs which are incorrectly cased (e.g. emacs). Introduce an explicit wrapper type for Windows to make the lookup case insensitive, canonicalising the name to lowercase. This allows us to treat `Path` and `PATH` identically (along with any other environment variable and case matching) which respects the Windows behaviour. Additionally, migrate away from the POSIX variants which do not handle the case properly to the Windows version which does. Fixes: swiftlang#446
compnerd
added a commit
to compnerd/swift-tools-support-core
that referenced
this issue
Dec 11, 2023
Windows is case insensitive for the environment control block, which we did not honour. This causes issues when Swift is used with programs which are incorrectly cased (e.g. emacs). Introduce an explicit wrapper type for Windows to make the lookup case insensitive, canonicalising the name to lowercase. This allows us to treat `Path` and `PATH` identically (along with any other environment variable and case matching) which respects the Windows behaviour. Additionally, migrate away from the POSIX variants which do not handle the case properly to the Windows version which does. Fixes: swiftlang#446
compnerd
added a commit
to compnerd/swift-tools-support-core
that referenced
this issue
Dec 18, 2023
Windows is case insensitive for the environment control block, which we did not honour. This causes issues when Swift is used with programs which are incorrectly cased (e.g. emacs). Introduce an explicit wrapper type for Windows to make the lookup case insensitive, canonicalising the name to lowercase. This allows us to treat Path and PATH identically (along with any other environment variable and case matching) which respects the Windows behaviour. Additionally, migrate away from the POSIX variants which do not handle the case properly to the Windows version which does. The introduced type `ProcessEnvironmentBlock` is just a typealias, allowing access to the dictionary itself which is important to preserve the behaviour for the clients. The `CaseInsensitiveString` is a case insensitive, case preserving string representation that allows us to recreate the environment on Windows as the environment is case insensitive, so it should not be possible to have conflicts when reading the Process Environment Block from the Process Execution Block. This is a partial resolution to environment variable handling as the tools need subsequent changes to adopt the new API. Fixes: swiftlang#446
compnerd
added a commit
to compnerd/swift-tools-support-core
that referenced
this issue
Dec 18, 2023
Windows is case insensitive for the environment control block, which we did not honour. This causes issues when Swift is used with programs which are incorrectly cased (e.g. emacs). Introduce an explicit wrapper type for Windows to make the lookup case insensitive, canonicalising the name to lowercase. This allows us to treat Path and PATH identically (along with any other environment variable and case matching) which respects the Windows behaviour. Additionally, migrate away from the POSIX variants which do not handle the case properly to the Windows version which does. The introduced type `ProcessEnvironmentBlock` is just a typealias, allowing access to the dictionary itself which is important to preserve the behaviour for the clients. The `CaseInsensitiveString` is a case insensitive, case preserving string representation that allows us to recreate the environment on Windows as the environment is case insensitive, so it should not be possible to have conflicts when reading the Process Environment Block from the Process Execution Block. This is a partial resolution to environment variable handling as the tools need subsequent changes to adopt the new API. Fixes: swiftlang#446 Co-authored-by: Max Desiatov <[email protected]>
compnerd
added a commit
to compnerd/swift-tools-support-core
that referenced
this issue
Dec 18, 2023
Windows is case insensitive for the environment control block, which we did not honour. This causes issues when Swift is used with programs which are incorrectly cased (e.g. emacs). Introduce an explicit wrapper type for Windows to make the lookup case insensitive, canonicalising the name to lowercase. This allows us to treat Path and PATH identically (along with any other environment variable and case matching) which respects the Windows behaviour. Additionally, migrate away from the POSIX variants which do not handle the case properly to the Windows version which does. The introduced type `ProcessEnvironmentBlock` is just a typealias, allowing access to the dictionary itself which is important to preserve the behaviour for the clients. The `CaseInsensitiveString` is a case insensitive, case preserving string representation that allows us to recreate the environment on Windows as the environment is case insensitive, so it should not be possible to have conflicts when reading the Process Environment Block from the Process Execution Block. This is a partial resolution to environment variable handling as the tools need subsequent changes to adopt the new API. Fixes: swiftlang#446 Co-authored-by: Max Desiatov <[email protected]>
compnerd
added a commit
to compnerd/swift-tools-support-core
that referenced
this issue
Dec 19, 2023
Windows is case insensitive for the environment control block, which we did not honour. This causes issues when Swift is used with programs which are incorrectly cased (e.g. emacs). Introduce an explicit wrapper type for Windows to make the lookup case insensitive, canonicalising the name to lowercase. This allows us to treat Path and PATH identically (along with any other environment variable and case matching) which respects the Windows behaviour. Additionally, migrate away from the POSIX variants which do not handle the case properly to the Windows version which does. The introduced type `ProcessEnvironmentBlock` is just a typealias, allowing access to the dictionary itself which is important to preserve the behaviour for the clients. The `CaseInsensitiveString` is a case insensitive, case preserving string representation that allows us to recreate the environment on Windows as the environment is case insensitive, so it should not be possible to have conflicts when reading the Process Environment Block from the Process Execution Block. This is a partial resolution to environment variable handling as the tools need subsequent changes to adopt the new API. Fixes: swiftlang#446 Co-authored-by: Max Desiatov <[email protected]>
compnerd
added a commit
to compnerd/swift-tools-support-core
that referenced
this issue
Dec 19, 2023
Windows is case insensitive for the environment control block, which we did not honour. This causes issues when Swift is used with programs which are incorrectly cased (e.g. emacs). Introduce an explicit wrapper type for Windows to make the lookup case insensitive, canonicalising the name to lowercase. This allows us to treat Path and PATH identically (along with any other environment variable and case matching) which respects the Windows behaviour. Additionally, migrate away from the POSIX variants which do not handle the case properly to the Windows version which does. The introduced type `ProcessEnvironmentBlock` is just a typealias, allowing access to the dictionary itself which is important to preserve the behaviour for the clients. The `CaseInsensitiveString` is a case insensitive, case preserving string representation that allows us to recreate the environment on Windows as the environment is case insensitive, so it should not be possible to have conflicts when reading the Process Environment Block from the Process Execution Block. This is a partial resolution to environment variable handling as the tools need subsequent changes to adopt the new API. Fixes: swiftlang#446 Co-authored-by: Max Desiatov <[email protected]>
compnerd
added a commit
to compnerd/swift-tools-support-core
that referenced
this issue
Dec 19, 2023
Windows is case insensitive for the environment control block, which we did not honour. This causes issues when Swift is used with programs which are incorrectly cased (e.g. emacs). Introduce an explicit wrapper type for Windows to make the lookup case insensitive, canonicalising the name to lowercase. This allows us to treat Path and PATH identically (along with any other environment variable and case matching) which respects the Windows behaviour. Additionally, migrate away from the POSIX variants which do not handle the case properly to the Windows version which does. The introduced type `ProcessEnvironmentBlock` is just a typealias, allowing access to the dictionary itself which is important to preserve the behaviour for the clients. The `CaseInsensitiveString` is a case insensitive, case preserving string representation that allows us to recreate the environment on Windows as the environment is case insensitive, so it should not be possible to have conflicts when reading the Process Environment Block from the Process Execution Block. This is a partial resolution to environment variable handling as the tools need subsequent changes to adopt the new API. Fixes: swiftlang#446 Co-authored-by: Max Desiatov <[email protected]>
compnerd
added a commit
to compnerd/swift-tools-support-core
that referenced
this issue
Dec 19, 2023
Windows is case insensitive for the environment control block, which we did not honour. This causes issues when Swift is used with programs which are incorrectly cased (e.g. emacs). Introduce an explicit wrapper type for Windows to make the lookup case insensitive, canonicalising the name to lowercase. This allows us to treat Path and PATH identically (along with any other environment variable and case matching) which respects the Windows behaviour. Additionally, migrate away from the POSIX variants which do not handle the case properly to the Windows version which does. The introduced type `ProcessEnvironmentBlock` is just a typealias, allowing access to the dictionary itself which is important to preserve the behaviour for the clients. The `CaseInsensitiveString` is a case insensitive, case preserving string representation that allows us to recreate the environment on Windows as the environment is case insensitive, so it should not be possible to have conflicts when reading the Process Environment Block from the Process Execution Block. This is a partial resolution to environment variable handling as the tools need subsequent changes to adopt the new API. Fixes: swiftlang#446 Co-authored-by: Max Desiatov <[email protected]>
compnerd
added a commit
to compnerd/swift-tools-support-core
that referenced
this issue
Dec 19, 2023
Windows is case insensitive for the environment control block, which we did not honour. This causes issues when Swift is used with programs which are incorrectly cased (e.g. emacs). Introduce an explicit wrapper type for Windows to make the lookup case insensitive, canonicalising the name to lowercase. This allows us to treat Path and PATH identically (along with any other environment variable and case matching) which respects the Windows behaviour. Additionally, migrate away from the POSIX variants which do not handle the case properly to the Windows version which does. The introduced type `ProcessEnvironmentBlock` is just a typealias, allowing access to the dictionary itself which is important to preserve the behaviour for the clients. The `CaseInsensitiveString` is a case insensitive, case preserving string representation that allows us to recreate the environment on Windows as the environment is case insensitive, so it should not be possible to have conflicts when reading the Process Environment Block from the Process Execution Block. This is a partial resolution to environment variable handling as the tools need subsequent changes to adopt the new API. Fixes: swiftlang#446 Co-authored-by: Max Desiatov <[email protected]>
compnerd
added a commit
that referenced
this issue
Dec 19, 2023
Windows is case insensitive for the environment control block, which we did not honour. This causes issues when Swift is used with programs which are incorrectly cased (e.g. emacs). Introduce an explicit wrapper type for Windows to make the lookup case insensitive, canonicalising the name to lowercase. This allows us to treat Path and PATH identically (along with any other environment variable and case matching) which respects the Windows behaviour. Additionally, migrate away from the POSIX variants which do not handle the case properly to the Windows version which does. The introduced type `ProcessEnvironmentBlock` is just a typealias, allowing access to the dictionary itself which is important to preserve the behaviour for the clients. The `CaseInsensitiveString` is a case insensitive, case preserving string representation that allows us to recreate the environment on Windows as the environment is case insensitive, so it should not be possible to have conflicts when reading the Process Environment Block from the Process Execution Block. This is a partial resolution to environment variable handling as the tools need subsequent changes to adopt the new API. Fixes: #446 Co-authored-by: Max Desiatov <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Trying to run swift from emacs on windows (niche use case, I know) I was running into an error about swift not being able to find "swift-test.exe". Checking environment variables, I think I've tracked this down to a combination of emacs using unconventional capitalization, and a case sensitivity inside of SPM.
When run from cmd.exe, the environment variable is
Path=C:\..., but from emacs it'sPATH=C:\...From https://github.com/apple/swift-tools-support-core/blob/4d539ff4c3d75394a78e17f68b675ad82434dd71/Sources/TSCBasic/ProcessEnv.swift#L55-L62
it looks like swift is looking for the "Path" one and not doing the typical-on-windows case insensitive lookup.
This brings me finally to a question: Is this a swift bug and/or an emacs bug? As far as I understand, while "Path" is the official casing, environment variables are expected to be treated insensitively on windows (which works a bit unfortunately with swift's representation as
[String: String])I can create a PR to fix this, and I may file a bug against emacs as well, but I wanted to check first, since my windows experience is pretty limited.
The text was updated successfully, but these errors were encountered: