Fix xvfb-run failure when environment variables with spaces exist

[chuckg]

Description

There is a bug in the StandaloneDebug entry_point.sh that, when encountering an environment variable with a space in it's value, causes the xvfb-run ... step to fail. This is due to how the command inlines environment variables found in the root user's environment that are not present in the seluser's environment into the xvfb-run ... step.

Notes

• Initially tried fixing the inline, but couldn't get the return codes to work with all the subshell slinging, so I opted for an environment file and simply sourcing it inline with the xvfb-run ...
• Thought using envdir instead instead, but opted for not adding packages and going at it in a more traditional way.
• Resolves Docker for Mac beta - containers do not start #227
• The issue was originally introduced in manullay transmit env variables to selenium user in *debug* #131

How to reproduce

After adding an environment variable with a space, ie: NO_PROXY="*.local, 10.254/16" to my docker run, the error is immediately reproducible:

$ make standalone_chrome_debug
...
Successfully built 6a0b1ab25668

$ docker run -e NO_PROXY="*.local, 10.254/16" --rm selenium/standalone-chrome-debug:2.53.0 env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=6a00c5bf0dd2
NO_PROXY=*.local, 10.254/16
DEBIAN_FRONTEND=noninteractive
DEBCONF_NONINTERACTIVE_SEEN=true
TZ=US/Pacific
SCREEN_WIDTH=1360
SCREEN_HEIGHT=1020
SCREEN_DEPTH=24
DISPLAY=:99.0
CHROME_DRIVER_VERSION=2.21
DBUS_SESSION_BUS_ADDRESS=/dev/null
LANGUAGE=en_US.UTF-8
LANG=en_US.UTF-8
HOME=/root

$ docker run -e NO_PROXY="*.local, 10.254/16" --rm selenium/standalone-chrome-debug:2.53.0
Waiting xvfb...
-bash: 10.254/16: No such file or directory
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...

Testing

$ git checkout fix/xvfb-run_env_constructor
$ make standalone_chrome_debug
$ docker run -e NO_PROXY="*.local, 10.254/16" --rm selenium/standalone-chrome-debug:2.53.0
Waiting xvfb...
Failed to read: session.ignoreBorder
Setting default value
...
20/07/2016 15:03:47 screen setup finished.
20/07/2016 15:03:47

The VNC desktop is:      c5399f058668:0
...
<etc>

[oiwn]

damn, same thing. Debug containers do not work.

[ddavison]

this is only Mac specific, and can be easily circumvented by specifying some options.

In the meantime, you can override the no_proxy variable by adding it yourself in docker run -e no_proxy=""
The value you are seeing is picked up from OSX as it seems to be added automatically to some connections. We had a bug in Beta 13 that caused this value to get passed through to Docker for Mac even if you hadn't specified a HTTP Proxy. This was fixed in Beta 13.1. If you are running Beta 13.1, a reset to factory defaults may remove the bad state for the no_proxy variable.
Source

[chuckg]

@ddavison Thank you for the reference to the specific issue with NO_PROXY, I'm glad to hear that it's being addressed by the Docker team. This isn't a pull request to fix an issue with using Docker on Mac, it's to fix a bug when someone passes an environment variable with one or more spaces in it.

> docker run -e OTHER_VARIABLE_I_NEED="yup I'm bad" --rm selenium/standalone-chrome-debug:2.53.0
Looking for lock file: /tmp/.X??-lock
-bash: 169.254/16: No such file or directory
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...

Passing environment variables sanely and correctly to the Selenium runtime environment is important when using it as a key component to your build infrastructure.

[ddavison]

try and specify the no_proxy stuff in addition to your OTHER_VARIABLE_I_NEED. the "No Such file or directory" right there, is coming from that issue

[chuckg]

Apologies, I meant to include it:

> docker run -e NO_PROXY="" -e OTHER_VARIABLE_I_NEED="yup I'm bad" --rm selenium/standalone-chrome-debug:2.53.0
Looking for lock file: /tmp/.X??-lock
Waiting xvfb...
-bash: I'm: command not found
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...

[ddavison]

ok, seems also that this is a little out of date.. could you rebase please and push back up? hard to tell what's actually changing here 👍

[chuckg]

Done @ddavison.

[heathkit]

I was just about to send out a similar PR, hope this gets in soon!

[FelikZ]

Still relevant! For non-standalone version as well.

[Zechtitus]

Tried this on the node-chrome-debug and this fixes the issues there as well.

[deployable]

@ddavison Is this PR a chance of being merged soon? I just ran into the same whitespace issue.

[finspin]

The issue seems to be reproducible with macOS Sierra and not reproducible with El Capitan.

[deployable]

@finspin I've seen it on El Capitan too.

[ddavison]

merged in! working on releasing 3.2.0-actinium as we speak

[yamamoo]

Is this fix also needed in NodeChromeDebug/entry_point.sh and NodeFirefoxDebug/entry_point.sh? I'm having a problem running those nodes on Docker Swarm with SE_OPTS="-host xxx -port yyy". This adds an env variable value with spaces and causes xvfb-run to fail.

[BeyondEvil]

@yamamoo See this comment: #227 (comment)