Henrik Nordstrom wrote:
fre 2006-03-17 klockan 19:31 -0800 skrev Linda W:
Mystery solved.
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
