Re: _AC_CACHE_DUMP simplified

[Ralf Wildenhues]

Hi Eric, Paul, Stepan,

* Paul Eggert wrote on Wed, Apr 05, 2006 at 07:12:37AM CEST:
> address@hidden (Eric Blake) writes:
> >
> > the probability of configuring in an environment that polluted is
> > too small to be worried about (since we already have a tough time
> > handling newlines in the environment).
> 
> True.  But if that's a real concern, and I suppose it might be, then
> we can sanitize the environment on startup, with code that looks
> something like this:

Very clever algorithm, and only a tiny missing `$'.  I don't like the
"sanitizing on startup" idea though:

First, this assumes that all variables with newlines stem from the
environment.  That's not necessarily true: I was once "clever" enough
to store a value containing newlines in a *_cv_* shell variable in a
Libtool macro.  Of course without exporting it, and it would happen
only within the configure script.

Second, there may be valid uses of environment variables containing
newlines, but they won't ever end up in the cache file.  Imagine,
for example, an environment variable necessary for some compiler to
work.  Granted, it's not too common, but  now that we can substitute
values with newlines, I think we should not rule this out.


So, how about doing the sanitizing only right before we actually dump?
It's not too expensive, but also not very cheap, as we potentially go
through a lot of shell variables, so it'd be good to avoid if the user
does not use the cache, or the cache does not change.

Notes:
- We put the whole _AC_CACHE_DUMP in a subshell, to avoid unsetting
  any variables needed later.

- match `*${as_nl}?*' to avoid matching `$as_nl', thus unsetting
  `as_nl', which is needed later in that subshell.

- Don't unset `_' or `IFS', for obvious reasons.  Less obvious is
  which other system-specific variables should also be exempted..
  I guess bug reports will show..  :-/

- Warn for cache variables that are about to be unset.  Reformulate
  the warning so it fits both the cache saving and the appending of
  config.log.  Do not warn about unsetting other variables (there
  will always be some, for example ac_subst_vars, ac_includes_default..).

- The $as_unset without a subshell is ugly.  Strictly speaking, that
  would have to be
    ($as_unset $ac_var) >/dev/null 2>&1 && $as_unset $ac_var

  again, but can we just hope that the user never puts newlines in
  LC_*, ENV, MAIL, MAILPATH, and does not set other variables to
  readonly mode on that *&#^@ IRIX shell?

- The algorithm now actually allows us to put newlines in cache
  variables: they just simply won't be saved.  Provides a neat
  upgrade path, eh?  :-)

- I'll mention all four of us in the final ChangeLog entry.

I'm not certain I want this applied right now though, so I'd appreciate
your opinion on this.

Cheers,
Ralf

        * lib/autoconf/general.m4 (_AC_CACHE_DUMP): Fix the detection of
        whether `set' quotes correctly: redirect stderr of the tested
        `set', and use a subshell, for Ultrix; use `sed' instead of
        `grep' for zsh `set' which may write binary output; match only
        at the beginning of a line, to avoid false positives.
        In order to avoid false positives by unrelated variables with
        multiline content, put the dump algorithm in a subshell and
        unset all variables containing newlines (except some which are
        special to the shell).  Warn about cache variables that are
        unset.

Index: lib/autoconf/general.m4
===================================================================
RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/general.m4,v
retrieving revision 1.895
diff -u -r1.895 general.m4
--- lib/autoconf/general.m4     4 Apr 2006 16:13:47 -0000       1.895
+++ lib/autoconf/general.m4     5 Apr 2006 18:57:19 -0000
@@ -1807,13 +1807,25 @@
 m4_define([_AC_CACHE_DUMP],
 [# The following way of writing the cache mishandles newlines in values,
 # but we know of no workaround that is simple, portable, and efficient.
-# So, don't put newlines in cache variables' values.
+# So, we kill variables containing newlines.
 # Ultrix sh set writes to stderr and can't be redirected directly,
 # and sets the high bit in the cache file unless we assign to the vars.
-{
+(
+  for ac_var in `(set) 2>&1 | sed -n 
['s/^\([a-zA-Z_][a-zA-Z0-9_]*\)=.*/\1/p']`; do
+    eval ac_val=\$$ac_var
+    case $ac_val in #(
+    *${as_nl}?*)
+      case $ac_var in #(
+      _ | IFS) ;; #(
+      *_cv_*) AC_MSG_WARN([Cache variable $ac_var contains a newline.]) ;;
+      esac
+      $as_unset $ac_var ;;
+    esac
+  done
+
   (set) 2>&1 |
-    case `(ac_space=' '; set | grep ac_space) 2>&1` in
-    *ac_space=\ *)
+    case $as_nl`(ac_space=' '; set) 2>&1` in
+    *${as_nl}ac_space=\ *)
       # `set' does not quote correctly, so add quotes (double-quote
       # substitution turns \\\\ into \\, and sed turns \\ into \).
       sed -n \
@@ -1826,7 +1838,7 @@
        ["s/^\\([_$as_cr_alnum]*_cv_[_$as_cr_alnum]*\\)=\\(.*\\)/\\1=\\2/p"]
       ;;
     esac;
-}dnl
+)dnl
 ])# _AC_CACHE_DUMP