> What I'd suggest for the additional variables is that we export them as stuff like HOMEBREW_OLD_PATH and HOMEBREW_EDITOR and then we can use them when needed...
Not always possible, because environment variables can be expected by external commands, and (1) prefixing them makes them useless; (2) restoring them at the right point is both hard work and easily forgotten. Examples:
1. `CURL_HOME`. Without this user's curlrc may be ignored. (Yes, I do use a curlrc, and I'm well aware of the fact that doctor barks at its mere existence.)
2. `ZDOTDIR`. It doesn't appear anywhere in the source code, hence not in my list above. I use this to get a usable shell from debrew.
3. `EMACSPATH`, another example of an env var that doesn't appear in brew's code, but is useful for an external command that brew may invoke.
The point I'm trying to make is that it's both useful and easy to whitelist harmless environment variables that are *used by external commands invoked by brew that users are allowed to customize* (e.g., curl, emacs, zsh). On the ease of whitelisting:
```bash
WHITELIST=(
HOME
SHELL
PATH
TERM
LOGNAME
USER
# Used by external commands
CURL_HOME
# ...
)
FILTERED_ENV=()
for VAR in "${WHITELIST[@]}" "${!HOMEBREW_@}"
do
FILTERED_ENV+=( "${VAR}=${!VAR}" )
done
/usr/bin/env -i "${FILTERED_ENV[@]}" /bin/bash "$HOMEBREW_LIBRARY/Homebrew/brew.sh" "$@"
```
This structure also makes it easy for users to submit PRs when they notice something that should be whitelisted.
Of course there's also the possibility of whitelisting certain dev commands. For now I won't argue for it.