2018-01-29 16:18:43 -05:00
|
|
|
package loader
|
|
|
|
|
|
|
|
import (
|
|
|
|
"os"
|
|
|
|
"path/filepath"
|
stack/loader: Ignore cmd.exe special env variables
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>
2023-03-09 09:40:25 -05:00
|
|
|
"runtime"
|
2018-01-29 16:18:43 -05:00
|
|
|
"strings"
|
|
|
|
"testing"
|
|
|
|
|
2020-02-22 12:12:14 -05:00
|
|
|
"gotest.tools/v3/assert"
|
|
|
|
is "gotest.tools/v3/assert/cmp"
|
|
|
|
"gotest.tools/v3/fs"
|
2018-01-29 16:18:43 -05:00
|
|
|
)
|
|
|
|
|
|
|
|
func TestGetConfigDetails(t *testing.T) {
|
|
|
|
content := `
|
|
|
|
version: "3.0"
|
|
|
|
services:
|
|
|
|
foo:
|
|
|
|
image: alpine:3.5
|
|
|
|
`
|
|
|
|
file := fs.NewFile(t, "test-get-config-details", fs.WithContent(content))
|
|
|
|
defer file.Remove()
|
|
|
|
|
2020-09-22 05:16:05 -04:00
|
|
|
details, err := GetConfigDetails([]string{file.Path()}, nil)
|
2018-03-05 18:53:52 -05:00
|
|
|
assert.NilError(t, err)
|
|
|
|
assert.Check(t, is.Equal(filepath.Dir(file.Path()), details.WorkingDir))
|
|
|
|
assert.Assert(t, is.Len(details.ConfigFiles, 1))
|
|
|
|
assert.Check(t, is.Equal("3.0", details.ConfigFiles[0].Config["version"]))
|
|
|
|
assert.Check(t, is.Len(details.Environment, len(os.Environ())))
|
2018-01-29 16:18:43 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
func TestGetConfigDetailsStdin(t *testing.T) {
|
|
|
|
content := `
|
|
|
|
version: "3.0"
|
|
|
|
services:
|
|
|
|
foo:
|
|
|
|
image: alpine:3.5
|
|
|
|
`
|
2020-09-22 05:16:05 -04:00
|
|
|
details, err := GetConfigDetails([]string{"-"}, strings.NewReader(content))
|
2018-03-05 18:53:52 -05:00
|
|
|
assert.NilError(t, err)
|
2018-01-29 16:18:43 -05:00
|
|
|
cwd, err := os.Getwd()
|
2018-03-05 18:53:52 -05:00
|
|
|
assert.NilError(t, err)
|
|
|
|
assert.Check(t, is.Equal(cwd, details.WorkingDir))
|
|
|
|
assert.Assert(t, is.Len(details.ConfigFiles, 1))
|
|
|
|
assert.Check(t, is.Equal("3.0", details.ConfigFiles[0].Config["version"]))
|
|
|
|
assert.Check(t, is.Len(details.Environment, len(os.Environ())))
|
2018-01-29 16:18:43 -05:00
|
|
|
}
|
stack/loader: Ignore cmd.exe special env variables
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>
2023-03-09 09:40:25 -05:00
|
|
|
|
|
|
|
func TestBuildEnvironment(t *testing.T) {
|
|
|
|
inputEnv := []string{
|
|
|
|
"LEGIT_VAR=LEGIT_VALUE",
|
|
|
|
"EMPTY_VARIABLE=",
|
|
|
|
}
|
|
|
|
|
|
|
|
if runtime.GOOS == "windows" {
|
|
|
|
inputEnv = []string{
|
|
|
|
"LEGIT_VAR=LEGIT_VALUE",
|
|
|
|
|
|
|
|
// cmd.exe has some special environment variables which start with "=".
|
|
|
|
// These should be ignored as they're only there for MS-DOS compatibility.
|
|
|
|
"=ExitCode=00000041",
|
|
|
|
"=ExitCodeAscii=A",
|
|
|
|
`=C:=C:\some\dir`,
|
|
|
|
`=D:=D:\some\different\dir`,
|
|
|
|
`=X:=X:\`,
|
|
|
|
`=::=::\`,
|
|
|
|
|
|
|
|
"EMPTY_VARIABLE=",
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
env, err := buildEnvironment(inputEnv)
|
|
|
|
assert.NilError(t, err)
|
|
|
|
|
|
|
|
assert.Check(t, is.Len(env, 2))
|
|
|
|
assert.Check(t, is.Equal("LEGIT_VALUE", env["LEGIT_VAR"]))
|
|
|
|
assert.Check(t, is.Equal("", env["EMPTY_VARIABLE"]))
|
|
|
|
}
|