`env_file` values containing spaces are word-split and break the deploy

[ericof]

Summary

An env_file entry whose value contains a space is silently split, and the deploy fails with:

Environment Variables: Additional values
/docker-entrypoint.sh: line 44: export: `-Xmx1536m': not a valid identifier

The variable ends up set to the truncated first token, and every value on that line after the first space is passed to export as a separate argument.

Cause

scripts/docker-entrypoint.sh:

# shellcheck disable=SC2046
export $(grep -v '^#' ${ENV_FILE_PATH} | grep -v '^$' | xargs -d '\n')

xargs -d '\n' correctly keeps each line intact as one argument, but the result goes through an unquoted $(...), so the shell word-splits it on whitespace before export ever runs. SC2046 — "Quote this to prevent word splitting" — is the exact warning for this, and it is suppressed on the line above.

Quoting the value in the env file does not help, because the split happens after substitution. Reproduced with GNU xargs:

env file line	result
SOLR_JAVA_MEM=-Xms1536m -Xmx1536m	export: `-Xmx1536m': not a valid identifier, value -Xms1536m
SOLR_JAVA_MEM="-Xms1536m -Xmx1536m"	same error, value "-Xms1536m
SOLR_JAVA_MEM='-Xms1536m -Xmx1536m'	same error, value '-Xms1536m
SOLR_JAVA_MEM=-Xmx1536m	works

So no quoting style in ENV_FILE can express a value containing a space.

Impact

Any variable with a space in its value. JVM options are the obvious case — SOLR_JAVA_MEM, JAVA_OPTS, JAVA_TOOL_OPTIONS — but it applies to connection strings, user agents, and anything else with a space.

The failure is easy to misread: export names the second token, which looks like a malformed variable name rather than a splitting problem in the action.

Suggested fix

Read the file line by line and quote the argument, so export receives NAME=value with spaces as a single argument:

while IFS= read -r line; do
  case "$line" in ''|\#*) continue ;; esac
  export "$line"
done < "${ENV_FILE_PATH}"

This keeps the current unquoted env-file format working unchanged, still skips comments and blank lines, and lets the shellcheck disable=SC2046 be removed rather than carried.

Verified: with this loop, SOLR_JAVA_MEM=-Xms1536m -Xmx1536m and DB_USER=plone in the same file both export correctly.

One behavioural note worth deciding on: the current code exports nothing at all if any line is malformed, whereas the loop exports line by line. If failing fast is preferred, the loop can validate NAME= with a pattern and exit non-zero on a bad line — that would also give a much clearer error than the current one.