Ignore DOCKER_XXX env vars when they are commented out

[gkeramidas]

When DOCKER_XXX environment settings are commented out, e.g. to test docker-osx-dev setup, the script still fails with a warning because it matches stuff like this too:

    ## Commented out for docker-osx-dev demo
    ## export DOCKER_HOST=stuff

This should not fail, but it does and prints a warning about environment settings which are not there.

A future improvement would probably be to replace the grep commands which look at .bashrc with something which runs bash in interactive mode and greps the output of "env" instead, e.g.:

    function env_is_defined() {
        local var="$1"
        if test -z "${var}" ; then
            echo >&2 "internal error: no var specified for env_is_defined"
            exit 1
        fi

        local setting=$( "${SHELL}" -i -c "env | grep \"^${var}=\"" )
        if test -n "${setting}" ; then
            value=$( echo "${setting}" | sed -e 's/^[^=]*=//' )
            echo >&2 "WARNING: ${var} is set to ${value}"
            echo >&2 "WARNING: Please remove ${var} from the startup settings of ${SHELL}"
            return 1
        fi
    }

[brikis98]

Ah, great catch, thank you!

Using env | grep is a great idea too, especially as there are many ways you could set an environment variable outside of ~/.bashrc. Maybe this is a dumb question, but why do you need to run it in an interactive shell? Why would calling env | grep -q foo directly in setup.sh not work?

[gkeramidas]

Running a subshell is an attempt to get hold of the state of a "just spawned" shell, regardless of what the docker-osx-dev setup script itself may have done in the environment of the shell which runs the installation commands. This way we can be relatively sure that "env" prints the environment that a new shell, spawned by the user, would get. So if one's .bashrc has for example an export command for DOCKER_HOST but the user runs:

unset DOCKER_HOST
cd docker-osx-dev && ./setup.sh

If we run just "env | grep" we will be looking only at the current process environment, which doesn't include DOCKER_HOST anymore. The setup script will think everything's fine, but then new shells will get the original DOCKER_HOST value and fail.

[brikis98]

Ah, that makes sense. I filed #19 to track this.