Quoted Env Vars (with whitespace) now retain their quotes everywhere #7164
Description
Up until this morning i was using docker-compose version 1.24.0
my colleague is running 1.24.1 and we have 1.25.0 on our production systems.
We noticed a discrepancy with the handling of env vars with whitespace.
Following the instructions (vars with spaces must be quoted) we enclosed our store name with double quotes like so:
STORE_NAME="Cool Store"
On my local environment this is converted to string and is properly displayed without the quote everywhere it is used,
On our production systems and my colleague's machine the quotes are still present everywhere it is used (in a PHP/Symfony4.3 Application) And when used as part of an email's subject line, get converted to ugly html entities.
Our hunch here is that it has something to do with the way the env vars are being passed into the system. If they are system env vars in the docker container, they will overrule any .env instances of the same variable.
It looks like this behaviour has changed somewhere around v1.24.
The only workaround in our PHP app is to manually strip the quotes from the variable before using it. but this is not an ideal solution. I would regard this as a BC or regression.
Could this possibly be connected to the discontinued support for variable names with whitespace ??? If so that change should not be affecting the values too....
DC versions
v1.24.0 (Linux Mint 19.3) issue doesn't show
v1.24.1 (Win10) issue shows
v1.25.0 (Ubuntu Server 18 LTS) issue shows
Output of docker-compose config
Can't post this output as it contains some sensitive data, BUT I can tell you that the affected variables appear in this output quoted twice, like this:
STORE_NAME='"Cool Store"'
Looks like it could be related to #2854
Although there is a PR referenced in the issue discussion, it has not yet been merged, and therefore doesn't explain why this has been working just fine for me until this morning's upgrade.
It may be that merging #6923 is the required fix, but if this is caused by something else, perhaps figuring out the cause of the regression is a better way to go.