Hello Eric,
* Eric Blake wrote on Tue, Oct 28, 2008 at 12:39:35PM CET:
> According to Ralf Wildenhues on 10/28/2008 12:42 AM:
> >> +ac_cr=`echo X | tr X '\015'`
> >
> > Are we going to ignore non-ASCII systems now?
>
> Not in this particular case. The only use of $ac_cr is to decide whether
> to initialize ac_cs_awk_cr to '\r' or "$ac_cr"; on non-ASCII systems, \015
> is _not_ carriage return, which means on those systems, the use of
> $ac_cs_awk_cr is idempotent (converting byte \015 to itself).
The code in question (in lib/autoconf/status.m4) looks like this now:
ac_cr=`echo X | tr X '\015'`
ac_cs_awk_cr=`$AWK 'BEGIN { print "a\rb" }' </dev/null 2>/dev/null`
if test "$ac_cs_awk_cr" = "a${ac_cr}b"; then
ac_cs_awk_cr='\\r'
else
ac_cs_awk_cr=$ac_cr
fi
...
if sed "s/$ac_cr//" < /dev/null > /dev/null 2>&1; then
sed "s/$ac_cr\$//; s/$ac_cr/$ac_cs_awk_cr/g"
else
cat
fi < "$tmp/subs1.awk" > "$tmp/subs.awk" \
...
If $ac_cr is a character other than carriage return, then that other
character will be deleted when it shows up as the last character in
a line of the subs1.awk file. The latter cannot happen: by design,
the last character in subs1.awk lines is always a double-quote, unless
line ending conventions get mixed up, in which case it could be a
carriage return (IIRC we had a bug report about this).
However, this now means that, on non-ASCII systems, the first 'if' above
can never be true, so the last 'sed' is idempotent. This is a bug iff,
on that system, awk understands \r but not literal carriage return.
I have no idea how likely this is.
However (2), all EBCDIC code pages I found show \015 as being carriage
return. So I think your patch is ok, but for completely different
reasons. :-)
Cheers,
Ralf
