From: Juan Quintela <quintela@redhat.com>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
qemu-devel@nongnu.org, qemu-stable@nongnu.org
Subject: Re: [PULL 04/12] configure: unset harmful environment variables
Date: Sun, 28 May 2023 20:11:33 +0200 [thread overview]
Message-ID: <87h6rw1g2y.fsf@secure.mitica> (raw)
In-Reply-To: <39719712-9058-aac2-247c-8dfb2c2622c7@tls.msk.ru> (Michael Tokarev's message of "Sat, 27 May 2023 18:57:08 +0300")
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.
next prev parent reply other threads:[~2023-05-28 18:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-26 16:08 [PULL 00/12] (Mostly) build system patches for 2023-05-26 Paolo Bonzini
2023-05-26 16:08 ` [PULL 01/12] tests/docker: simplify HOST_ARCH definition Paolo Bonzini
2023-05-26 16:08 ` [PULL 02/12] tests/vm: fix and " Paolo Bonzini
2023-05-26 16:08 ` [PULL 03/12] Makefile: remove $(TESTS_PYTHON) Paolo Bonzini
2023-05-26 16:08 ` [PULL 04/12] configure: unset harmful environment variables Paolo Bonzini
2023-05-27 15:57 ` Michael Tokarev
2023-05-28 18:11 ` Juan Quintela [this message]
2023-05-26 16:08 ` [PULL 05/12] meson: Remove leftover comment Paolo Bonzini
2023-05-26 16:08 ` [PULL 06/12] meson: Add static glib dependency for initrd-stress.img Paolo Bonzini
2023-05-26 16:08 ` [PULL 07/12] slirp: update wrap to latest master Paolo Bonzini
2023-05-26 16:08 ` [PULL 08/12] virtio: qmp: fix memory leak Paolo Bonzini
2023-05-27 9:30 ` Michael Tokarev
2023-05-26 16:08 ` [PULL 09/12] meson: simplify logic for -Dfdt Paolo Bonzini
2023-05-26 16:08 ` [PULL 10/12] meson: use subproject for internal libfdt Paolo Bonzini
2023-05-26 16:08 ` [PULL 11/12] meson: use subproject for keycodemapdb Paolo Bonzini
2023-05-26 16:08 ` [PULL 12/12] configure: ignore --make Paolo Bonzini
2023-05-27 0:16 ` [PULL 00/12] (Mostly) build system patches for 2023-05-26 Richard Henderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h6rw1g2y.fsf@secure.mitica \
--to=quintela@redhat.com \
--cc=mjt@tls.msk.ru \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).