echo "enhancement" [sic?] confuses autoconf...

[L. A. Walsh]

Found this when building "squid-3-beta" on w/shell "bash-3.1, compiled
with "--enable_xpg_default":

autoconf is using "echo" to enter the 2-byte strings '\1' and '\2' into
an awk script.

Under various unix shells, some strings are expanded into control
characters and "\0NNN" can be used to enter any 1-3 character octal
code.  Under those shells, the leading "0" is required.

Unfortunately, some versions of echo no longer require the "0" prefix
to indicate an octal string (gnu coreutils /bin/echo and bash's built-in
echo to name two).  The result is that extended echo processing turns
"\1" and "\2" into control-A and control-b rather than the awk arguments
they were intended to be.

The problem is compounded in bash in that it can be built with the
"--enable_xpg_default" option to comply with some "XPG" standard
as well as SysV and ksh.  In that mode, a standard echo will interpret
"\1" as an octal sequence. 

It may be the case that "autoconf" may wish to protect itself against
these versions of echo regardless of whether or it's considered a bug
in those versions.


> fre 2006-03-17 klockan 19:31 -0800 skrev Linda W:

> > My shell _expanded_ control sequences by default in echo. (echo "\1" -> becomes 
> > "echo ^A").
> >
> > Apparently there are literals in the configure script like "\\1" "\\2" that
> > were trying to echo a literal '\1' into a "sed" script.  Instead it was
> > echoed in as a control-A.
>
> Hmm.. so you have replaced /bin/sh with something else than a UNIX
> shell? Or was it you /bin/echo being different?
---
        It was the builtin on "bash" compiled to adhere with
the System-V standard, and some implementations of ksh and other
unix implementations.  See 
"http://ou800doc.caldera.com/en/man/html.1/echo.1.html";.


> > Am I misremembering, aren't their systems were expanded echo is the default?
>
> If so then the GNU autoconf people have not run into it yet..
---
        Well that could be because the feature was "extended" in BASH.
The original standard requires "\0" before an octal number consisting of 1-3
digits.  This required \0 to invoke the special decoding.

        Bash added the "feature" to allow dropping of the leading
"0",  accepting strings: "\0nnn", "\nnn", and "\xHH".  I'm guessing that
most bash users run in a shell that has expansion turned off by default or
this would have come up before.  I am leaning toward
thinking this is a case of Bash implementing an incompatible and conflicting
extension (by allowing the dropping of the leading 0 of an octal sequence).

> Good you found what it was, and a way around the problem. Even better if
> you would enlighten us what it was you were using causing the problem,
> and how you worked around it.
---
        For now, I disabled expansion, since it isn't compatible (as you note
with existing scripts (like autoconf).   Meanwhile, I've submitted a suggestion
to go back to requiring the full prefix "\0" before possible interpretation as
octal.  It seems cleanest if they require "\0" before either an octal or hex
encoding, with hex using \0xH[H] and octal using \0N[N[N]].

Linda