Re: RFC: Changing AC_DEFINE

[Paul Eggert]

> From: Alexandre Oliva <address@hidden>
> Date: 01 Jun 2001 17:33:39 -0300
> 
> you generally can't tell at autoconf-time whether there are going to
> be funky characters in the macro definition so, in general, you'll
> need to test it at run-time, and then, you'll have a here-doc anyway
> in case there are funky characters.  Right?

I suppose that you could optimize only the cases where you know at
compile-time that there cannot possibly be funky characters.  However,
unless you have a lot of free time to work on this I wouldn't bother.
Just tell users to get a faster shell.  That will save both their time
and yours.

So, how about this documentation patch to address the matter?  It
implements the above suggestion, along with mentioning the problems
with "echo" a bit more clearly (and fixing the manual to follow its
own new advice about "echo").

2001-06-01  Paul Eggert  <address@hidden>

        * doc/autoconf.texi: Talk about here documents and speedups.
        Do not use "echo" on arbitrary strings.
        Spell "here-documents" consistently with the standard.

===================================================================
RCS file: doc/autoconf.texi,v
retrieving revision 2.50
retrieving revision 2.50.0.1
diff -pu -r2.50 -r2.50.0.1
--- doc/autoconf.texi   2001/05/19 16:51:29     2.50
+++ doc/autoconf.texi   2001/06/01 21:48:46     2.50.0.1
@@ -5235,7 +5235,7 @@ echo "Don't use it: $?"
 don't use command substitution within variable expansion:
 
 @example
-echo address@hidden@}
+cat address@hidden@}
 @end example
 
 @item
@@ -5255,7 +5255,7 @@ details.
 @item @command{/bin/sh} on OpenBSD
 @cindex @command{/bin/sh} on OpenBSD
 
address@hidden"} expands to @samp{"} in here-in documents with unquoted
address@hidden"} expands to @samp{"} in here-documents with unquoted
 delimiter in the native @command{/bin/sh} on OpenBSD 2.7.  As a general
 rule, if @samp{\\} expands to @samp{\} use @samp{\\} to get @samp{\}.
 Don't rely on @samp{\} being preserved just because it has no special
@@ -5339,8 +5339,8 @@ In each case the expected result is of c
 
 Don't try to redirect the standard error of a command substitution: it
 must be done @emph{inside} the command substitution: when running
address@hidden `cd /zorglub` 2>/dev/null} expect the error message to
-escape, while @samp{echo `cd /zorglub 2>/dev/null`} works properly.
address@hidden: `cd /zorglub` 2>/dev/null} expect the error message to
+escape, while @samp{: `cd /zorglub 2>/dev/null`} works properly.
 
 It is worth noting that Zsh (but not Ash nor Bash) makes it possible
 in assignments though: @samp{foo=`cd /zorglub` 2>/dev/null}.
@@ -5951,6 +5951,22 @@ Please note that the problem is truly @c
 understand @samp{'\n'} as the string composed of a backslash and an
 @samp{n}.
 
+Because of these problems, do not pass a string containing arbitrary
+characters to @command{echo}.  For example, @samp{echo "$foo"} is safe
+if you know that @var{foo}'s value cannot contain backslashes and cannot
+start with @samp{-}, but otherwise you should use a here-document like
+this:
+
address@hidden
+cat <<EOF
+$foo
+EOF
address@hidden example
+
+Many older shells (including the Bourne shell) implement here-documents
+inefficiently.  Users can generally speed things up by using a faster
+shell, e.g., by using the command @samp{bash ./configure} rather than
+plain @samp{./configure}.
 
 @item @command{exit}
 @c -----------------