Handle quotes in --env-file values consistently with Linux/WSL2 "source"ing

[markm77]

Hi there,

I use a .env file to supply env vars for my application both when running locally and in a Docker container.

When running my application in Linux/WSL2 (Ubuntu), I source the .env file before running.

Example:

set -o allexport
source ./myVars.env
set +o allexport

And when running my application in Docker Desktop on Windows I use the --env-file option to specify the .env file:

docker run --env-file  .\myVars.env <etc>

Unfortunately, some of the env var values in the .env file need to contain spaces. This means they must be double-quoted to work correctly when sourceing in Linux. However when quoted, the parsing in docker run does not remove the quotes making the values invalid as they contain literal quote marks at beginning and end.

The consequence of this is I need to maintain a second (mostly duplicate) .env file for Docker use.

I would much prefer if docker run could parse .env files in the same way as my Linux sourceing does and in line with the general shell concept that quotes are a guide to how a string should be interpreted - not part of the string itself.

From searching, it seems this has been fixed in docker compose (https://github.com/docker/compose/issues/8388). Please can you also fix it in docker run?

[ToshY]

What's the status on this issue and the corresponding PR?

[ivan-kleshnin]

Swarm and Compose see the same value differently 😨

JWT_SECRET='{"type": "HS256", "key": "xxx"}'

$ docker compose up ... with .env_file

[container] $ echo $JWT_SECRET
{"type": "HS256", "key": "xxx"}

$ docker stack deploy ... with .env_file

[container] $ echo $JWT_SECRET
'{"type": "HS256", "key": "xxx"}'

[4nif]

Hopefully this can get fix soon

[TheodorRene]

Yes, this stumped me for a while as well. Worked nice locally, but not when dockerized. Even more confusing when compose would've handled the variables differently.

[ulbi]

Just run into the same problem, either the script works locally OR in the container, but never in both. This is really useless and forces keeping the same content twice. Please fix this soon.

[thaJeztah]

Let me copy my comment over from https://github.com/docker/cli/issues/4665#issuecomment-1821862464

The value should be unquoted as documented for docker compose (https://docs.docker.com/compose/compose-file/05-services/#env_file)

Unfortunately that format is a breaking change introduced in compose, and I wonder if that change was intentional or because they conflated the format for the .env file and --env-file, which are very different. The --env-file format was designed to be a plain NAME=value, no parsing, and no handling on quotes.

The only processing happening is if a NAME is provided without = / =value, the value of NAME is set from an $NAME env-var if present in the current environment; https://docs.docker.com/engine/reference/commandline/run/#env

[thaJeztah]

@glours do you know if the change in format for --env-file in compose was an intentional change (as it's diverging from docker run --env-file, and a backward-incompatible change)?

[0xGuybrush]

I've just spent a good while debugging an issue off the back of this, which is colouring my view, but I think this design choice is really confusing —

The --env-file format was designed to be a plain NAME=value, no parsing, and no handling on quotes.

At the moment, my natural inclination is to expect it to behave as per any other .env file parsing in other languages/frameworks.

The docs also make it sound as if -e and --env-file behave comparably (by grouping them together and not calling out the distinction), but the -e does parse quotes correctly (or at least they're parsed by the OS before assigning)

Personally, I'd much prefer if --env-file did unwrap quotes from the values, but if not then the 'principle of least surprise' would be to call it something else at least IMO.

[Elio-FairlyMade]

Any updates on this issue ?

[siriele]

I just ran into this bug today, and it feels like this command should be removed or corrected. It doesn't make sense as is. Especially not according to the documentation

[andersonbrands]

@thaJeztah @glours

Do we have any update on this?

[pveierland]

Issue is currently preventing use of the env_file feature with docker stack. Currently placing env file sourcing inside a startup script to avoid issue.

[phrfpeixoto]

I just found this annoyed with the fact that --env-file does not handle quotes. Now I can't use the same .env file for both docker compose and regular docker run commands.

Please fix this.

[pirafrank]

an alternative may be to mount the env file itself, instead of giving it to docker CLI, like this:

docker run -v ./.env:/usr/src/app/.env your:image

of course you need to customize path names to your env inside and outside the container.

[woutervh]

A .env-file in the root of a project can used by several different tools

• bash / zsh /...
• any dotenv-parser in any language (python, ...)

you can source a .env-file in bash via

set -a && source .env && set +a

Although not officially formalized, it is quite universally understood that a .env-file needs to have a bash-compatible syntax. Nearly all dotenv-parsers correctly support quoting and variable substitution. EXCEPT docker .... for over a decade.

Fixing the quotes only fixes some symptoms.

[mccolljr]

I second the notion that .env files are typically understood to support, at a minimum, quoted values. I use .env files with four or five different tools. I can use the same .env files for all of those tools. Docker is the odd one out, and it is certainly unexpected. If the existing behavior of --env-file needs to be preserved, can we have a separate option like --dotenv-file which can accept the same sort of .env files that other dotenv-themed tools accept?