[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PULL 04/12] configure: unset harmful environment variables
|
From: |
Juan Quintela |
|
Subject: |
Re: [PULL 04/12] configure: unset harmful environment variables |
|
Date: |
Sun, 28 May 2023 20:11:33 +0200 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
Michael Tokarev <mjt@tls.msk.ru> wrote:
> 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..
CDPATH -> It broke my setup, I have had this on my .bashrc since the
90's:
export CDPATH=.:~/work:/scratch/
For the rest, I don't know. But if autoconf disables them, some weird
system, somewhere in the world makes this fail.
Later, Juan.
- [PULL 00/12] (Mostly) build system patches for 2023-05-26, Paolo Bonzini, 2023/05/26
- [PULL 01/12] tests/docker: simplify HOST_ARCH definition, Paolo Bonzini, 2023/05/26
- [PULL 02/12] tests/vm: fix and simplify HOST_ARCH definition, Paolo Bonzini, 2023/05/26
- [PULL 03/12] Makefile: remove $(TESTS_PYTHON), Paolo Bonzini, 2023/05/26
- [PULL 04/12] configure: unset harmful environment variables, Paolo Bonzini, 2023/05/26
- [PULL 08/12] virtio: qmp: fix memory leak, Paolo Bonzini, 2023/05/26
- [PULL 05/12] meson: Remove leftover comment, Paolo Bonzini, 2023/05/26
- [PULL 07/12] slirp: update wrap to latest master, Paolo Bonzini, 2023/05/26
- [PULL 09/12] meson: simplify logic for -Dfdt, Paolo Bonzini, 2023/05/26
- [PULL 10/12] meson: use subproject for internal libfdt, Paolo Bonzini, 2023/05/26
- [PULL 11/12] meson: use subproject for keycodemapdb, Paolo Bonzini, 2023/05/26
- [PULL 12/12] configure: ignore --make, Paolo Bonzini, 2023/05/26
- [PULL 06/12] meson: Add static glib dependency for initrd-stress.img, Paolo Bonzini, 2023/05/26
- Re: [PULL 00/12] (Mostly) build system patches for 2023-05-26, Richard Henderson, 2023/05/26