[23.0 backport] stack/loader: Ignore cmd.exe special env variables #4083
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
On Windows, ignore all variables that start with "=" when building an environment variables map for stack. For MS-DOS compatibility cmd.exe can set some special environment variables that start with a "=" characters, which breaks the general assumption that the first encountered "=" separates a variable name from variable value and causes trouble when parsing. These variables don't seem to be documented anywhere, but they are described by some third-party sources and confirmed empirically on my Windows installation. Useful sources: https://devblogs.microsoft.com/oldnewthing/20100506-00/?p=14133 https://ss64.com/nt/syntax-variables.html Known variables: - `=ExitCode` stores the exit code returned by external command (in hex format) - `=ExitCodeAscii` - same as above, except the value is the ASCII representation of the code (so exit code 65 (0x41) becomes 'A'). - `=::=::\` and friends - store drive specific working directory. There is one env variable for each separate drive letter that was accessed in the shell session and stores the working directory for that specific drive. The general format for these is: `=<DRIVE_LETTER>:=<CWD>` (key=`=<DRIVE_LETTER>:`, value=`<CWD>`) where <CWD> is a working directory for the drive that is assigned to the letter <DRIVE_LETTER> A couple of examples: `=C:=C:\some\dir` (key: `=C:`, value: `C:\some\dir`) `=D:=D:\some\other\dir` (key: `=C:`, value: `C:\some\dir`) `=Z:=Z:\` (key: `=Z:`, value: `Z:\`) `=::=::\` is the one that seems to be always set and I'm not exactly sure what this one is for (what's drive `::`?). Others are set as soon as you CD to a path on some drive. Considering that you start a cmd.exe also has some working directory, there are 2 of these on start. All these variables can be safely ignored because they can't be deliberately set by the user, their meaning is only relevant to the cmd.exe session and they're all are related to the MS-DOS/Batch feature that are irrelevant for us. Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com> (cherry picked from commit a47058b) Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Make the error more specific by stating that it's caused by a specific environment variable and not an environment as a whole. Also don't escape the variable to make it more readable. Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com> (cherry picked from commit 012b779) Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
thaJeztah
added
status/2-code-review
area/stack
platform/windows
kind/bugfix
Member
Author
neersighted
approved these changes
Mar 9, 2023
vvoland
approved these changes
Mar 10, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
On Windows, ignore all variables that start with "=" when building an environment variables map for stack.
For MS-DOS compatibility cmd.exe can set some special environment variables that start with a "=" characters, which breaks the general assumption that the first encountered "=" separates a variable name from variable value and causes trouble when parsing.
These variables don't seem to be documented anywhere, but they are described by some third-party sources and confirmed empirically on my Windows installation.
Useful sources:
https://devblogs.microsoft.com/oldnewthing/20100506-00/?p=14133
https://ss64.com/nt/syntax-variables.html
Known variables:
=ExitCodestores the exit code returned by external command (in hex format)=ExitCodeAscii- same as above, except the value is the ASCII representation of the code (so exit code 65 (0x41) becomes 'A').=::=::\and friends - store drive specific working directory. There is one env variable for each separate drive letter that was accessed in the shell session and stores the working directory for that specific drive. The general format for these is:=<DRIVE_LETTER>:=<CWD>(key==<DRIVE_LETTER>:, value=<CWD>) where is a working directory for the drive that is assigned to the letter <DRIVE_LETTER>A couple of examples:
=C:=C:\some\dir(key:=C:, value:C:\some\dir)=D:=D:\some\other\dir(key:=C:, value:C:\some\dir)=Z:=Z:\(key:=Z:, value:Z:\)=::=::\is the one that seems to be always set and I'm not exactly sure what this one is for (what's drive::?). Others are set as soon as you CD to a path on some drive. Considering that you start a cmd.exe also has some working directory, there are 2 of these on start.All these variables can be safely ignored because they can't be deliberately set by the user, their meaning is only relevant to the cmd.exe session and they're all are related to the MS-DOS/Batch feature that are irrelevant for us.
- What I did
- How I did it
- How to verify it
TestBuildEnvironment test
- Description for the changelog
Fix
docker stack deployfailing when running fromcmd.exeon Windows- A picture of a cute animal (not mandatory but encouraged)