26.05.2023 19:08, Paolo Bonzini wrote: ..
# Unset some variables known to interfere with behavior of common tools, -# just as autoconf does. -CLICOLOR_FORCE= GREP_OPTIONS= -unset CLICOLOR_FORCE GREP_OPTIONS +# just as autoconf does. Unlike autoconf, we assume that unset exists. +unset CLICOLOR_FORCE GREP_OPTIONS BASH_ENV ENV MAIL MAILPATH CDPATH
Wonder how relevant all this is. gnu grep (from coreutils) does not document and does not use $GREP_OPTIONS. While $BASH_ENV is relevant for non-interactive mode (ie, when running as a script), but this variable a) is not used when it is invoked as sh (as opposed to bash), and b) it is a way to pass actual additional configuration to the shell, -- we do not override $PATH, do we? So why we override $BASH_ENV? For example, with $BASH_ENV, one can turn on tracing of shell functions, which is nearly impossible now when everything is run from within meson. Ditto for $ENV. Others - MAIL and MAILPATH? - those are only relevant for interactive usage, and only when mail actually goes to /var/mail/$user (or equivalent), it does not matter for scripts at all. CLICOLOR_FORCE is interesting, and it was there before already. It looks like whomever set that, don't really care about things like ./configure failing due to grep et al trying to color-paint its output. This variable shouldn't be used normally, it smells like a single-use thing - eg, to force color when output is displayed within less(1), or when grepping output but keeping colors. If it is set in environment before ./configure is run, it's not our fault. Now we come to CDPATH. But even there, it should not contain something else besides "." (current dir) as the first element, it's kinda interesting when CDPATH has something else in there. We've been here for like decades, and this is the first time we've hit this. Do we _really_ need to reset all this? Especially the $ENV and $BASH_ENV thing, which are useful.. But oh well :) /mjt
