Dear List,
... confusion worse confounded:
as has been suggested, the problem is locale-related,
and now does not seem to have anything to do with
the glibc version (hurrah!). The remarks previously
posted to the list suggest that it is indeed a gawk-3.1.4
bug.
en_GB is all right
en_GB.iso88591 is all right
en_GB.utf8 shows the problem (gawk-3.1.4 misbehave
gawk-3.1.3 seems correct)
The text being handled here contains nothing
but elementary ASCII (invariant subset), so
the preferred encoding shouldn't matter as much
as all that... but there it is.
The output from 'locale' in the failing case (on my
LFS build) is
LANG=en_GB.utf8
LC_CTYPE="en_GB.utf8"
LC_NUMERIC="en_GB.utf8"
LC_TIME="en_GB.utf8"
LC_COLLATE="en_GB.utf8"
LC_MONETARY="en_GB.utf8"
LC_MESSAGES="en_GB.utf8"
LC_PAPER="en_GB.utf8"
LC_NAME="en_GB.utf8"
LC_ADDRESS="en_GB.utf8"
LC_TELEPHONE="en_GB.utf8"
LC_MEASUREMENT="en_GB.utf8"
LC_IDENTIFICATION="en_GB.utf8"
LC_ALL=
The alternative forms were achieved with
export LC_ALL=en_GB.iso88591
export LC_ALL=en_GB.utf8
with the predicatable output from `locale'.
These names are as returned by locale -a .
In my "normal" host set-up (Mandrake-10.1 but with
my own unpatched gcc-3.4.3
my own (not relevantly patched) kernel 2.6.11.6
Mandrake's glibc-2.3.3)
I see similar behaviour, but the names returned by locale -a ,
and used for testing, are
en_GB (the default)
en_GB.ISO-8859-1
en_GB.UTF-8
Bernard Leak.
--
Before they made me, they broke the mould
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
