Issues with sub_env

[edmorley]

sub_env() is currently:

# Usage: $ sub-env command
# Runs a subshell of specified command with user-provided config.
# NOTICE: Expects ENV_DIR to be set. WHITELIST & BLACKLIST are optional.
# Examples:
#    WHITELIST=${2:-''}
#    BLACKLIST=${3:-'^(GIT_DIR|PYTHONHOME|LD_LIBRARY_PATH|LIBRARY_PATH|PATH)$'}
sub_env() {
  (
    export_env $ENV_DIR $WHITELIST $BLACKLIST

    $1
  )
}

Few issues:

1. The comment implies that whitelist/blacklist are passed as positional parameters, but that's not the case (they have to be set in the global environment).
2. shellcheck currently warns:

In stdlib.sh line 119:
    export_env $ENV_DIR $WHITELIST $BLACKLIST
                        ^-- SC2153: Possible misspelling: WHITELIST may not be assigned, but whitelist is.
                                   ^-- SC2153: Possible misspelling: BLACKLIST may not be assigned, but blacklist is.

3. Only the first positional argument is run by sub-env, so if someone does eg sub-env pip install -r requirements.txt then only pip gets run, with the rest being dropped. (See https://github.com/heroku/heroku-buildpack-python/pull/417#issuecomment-316213832)

I think either:

1. sub-env should run $@ and ENV_DIR, WHITELIST and BLACKLIST should still be set via the environment (but the comment corrected, plus the fallback/defaults made more explicit).
2. sub-env should continue to run just $1, and accept the other settings as $2, $3 and $4. Callers who want to run a command with multiple parameters will then have to quote them to make sure they stay in $1, eg sub-env "pip install -r requirements.txt" ....

[kennethreitz]

Option 1 sounds like a more sane approach.