.env file whit variable with whitespace

[ping86]

Description of the issue

Context information (for bug reports)

Output of docker-compose version

docker-compose version 1.24.0, build 0aa59064
docker-py version: 3.7.2
CPython version: 3.6.8
OpenSSL version: OpenSSL 1.1.0j  20 Nov 2018

Output of docker version

Client:
 Version:           18.09.3
 API version:       1.39
 Go version:        go1.10.8
 Git commit:        774a1f4
 Built:             Thu Feb 28 06:53:11 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          18.09.3
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.8
  Git commit:       774a1f4
  Built:            Thu Feb 28 05:59:55 2019
  OS/Arch:          linux/amd64
  Experimental:     false

Output of docker-compose config
(Make sure to add the relevant -f and other flags)

ERROR: In file ./.env: environment variable name 'typesetting industry. Lorem Ipsum has been' may not contains whitespace.

Steps to reproduce the issue

1. Create .env file with the this content:

LOREM="Lorem Ipsum is simply dummy text of the printing and
typesetting industry. Lorem Ipsum has been
"

2. Use docker-compose config or docker-compose build commands

Observed result

This issue occurs in docker-compose 1.24.0

If we rollback to docker-compose 1.23.2 the issue is fixed:

sudo curl -L "https://github.com/docker/compose/releases/download/1.23.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

docker-compose build

docker-compose build
nginx uses an image, skipping
Building php
....

Expected result

Stacktrace / full error message

ERROR: In file ./.env: environment variable name 'typesetting industry. Lorem Ipsum has been' may not contains whitespace.
``

[ndeloof]

I downloaded docker-compose-1.23.2 trying to reproduce your issue with this minimal setup :

docker-compose.yml:

version: "3"
services:
    test:
            image: alpine
            command: 'echo hello $FOO !'

.env

FOO="bar
zot"

docker-compose up, both with 1.23 and 1.24 fail to run such a configuration.
Actually this feature was discussed on #3527 without any obvious fix on his way as env file support in docker engine do not support multilines. Please note that using quotes around a value do not wrap a value as it does in plan shell, as bash isn't involved in parsing the .env file.

[ve-chhavi]

I was getting the same error and i did not use export in .env file. I have defined the variable like this and it worked for me
var:FOO

[Hassanzadeh-sd]

remove whitespace between environments
FOO = "bar
to
FOO="bar

[syedrakib]

I want to set the following contents into a .env file which i will use in my docker-compose

ENV=dev
MY_SERVICE_ACCOUNT='{
  "type": "service_account",
  "project_id": "my-gcp-project",
  "private_key_id": "d8f6d9c92749",
  "private_key": "-----BEGIN PRIVATE KEY-----\nMIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwgWI8\naewdr8VbO2sRk1AgmYGCu9s=\n-----END PRIVATE KEY-----\n",
  "client_email": "xyz@my-gcp-project.iam.gserviceaccount.com",
  "client_id": "740",
  "auth_uri": "https://acnt.google.com/o/o2auth/auth",
  "token_uri": "https://o2auth.googleapi.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapi.com/o2auth/vX/cert",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/xyz%40my-gcp-project.iam.gserviceaccount.com"
}'
MY_PHRASE="boo yaa"

It contains a JSON key of a GCP IAM Service Account in it.

I want to save that key in an environment variable called $MY_SERVICE_ACCOUNT.

But i am getting a ...may not contain whitespace error.

How do i bypass this? The Service Account key will certainly have whitespaces and stuff.

[sudughonge]

^ Facing the same issue. I have an environment variable that has to have spaces

[lil12t]

I've got the same problem, the issue was in CI/CD config, it was SERVICE_NAME:'value' instead of SERVICE_NAME=value.

[mrkiril]

Hey, guys, welcome to the club. Hope soon we can use multiline variables

[kasztof]

Is there any update on this issue? It still doesn't work for me. My env varaible looks like this:

WORDPRESS_CONFIG_EXTRA="
define('JWT_AUTH_SECRET_KEY','<secret-key>');
define('JWT_AUTH_CORS_ENABLE', true);
define('EXAMPLE_PATH', dirname( __FILE__ ) . '/directory');
"

It works if I put everything in one line:
WORDPRESS_CONFIG_EXTRA=define('JWT_AUTH_SECRET_KEY','<secret-key>'); define('JWT_AUTH_CORS_ENABLE', true); define('EXAMPLE_PATH', dirname( __FILE__ ) . '/directory');
(however in the second example I don't need to use "", I think the use of double quotes is causing this problem)

[Moongazer]

Same problem: we try to add a JWT key-pair to our project-related .env because all the sensitive information should be in one place. Removing the line-breaks from the base64 string results in an PHP error ("PHP Warning: openssl_sign(): supplied key param cannot be coerced into a private key in /var/www/html/vendor/firebase/php-jwt/src/JWT.php line 209"), and keeping the line-breaks inside the .env results in the above mentioned error.

VENDOR_JWT_KEY_PUBLIC="-----BEGIN PUBLIC KEY-----
XIICIjANBgkqhkiG9w0BAQEFAAOCAg8A0IICCgKCAgEAwhHmVFFkX0FkNps0ufG5
...
meyHCHC3szwG6qDlzkxcmPcCAwEAAQ==
-----END PUBLIC KEY-----"

VENDOR_JWT_KEY_PRIVATE="-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----"

Edit: Workaround in this case was to replace the line-break by \n

[srgg]

@ndeloof Any chance to get this fixed in 2021?

[ndeloof]

@srgg This will be fixed by Compose V2 as joho/godotenv#118 is merged.

[namedgraph]

When is this going to be fixed??

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[srgg]

Does this fixed?

[stale]

This issue has been automatically marked as not stale anymore due to the recent activity.

[xi-ao]

I've noticed that - at least with version 2.6.1 - the behavior seems to be back to what it was before.
Which is

• good because this was the point of this ticket
• bad because all existing adaptations (using double-quotes to enclose strings) are now generating new problems (because double-quotes are included in the value) and need fixing again

😐

[ndeloof]

closing this issue as fixed.
sorry for those who had to workaround this bug and now have to adapt again for the actual fix 😓