April Chin wrote:
> > On Mon, 20 Oct 2008 19:16:20 +0100 Chris Ridd wrote:
> > > On 20 Oct 2008, at 18:58, Glenn Fowler wrote:
> >
> > > > On Mon, 20 Oct 2008 18:39:48 +0100 Chris Ridd wrote:
> > > >> On 20 Oct 2008, at 14:08, Glenn Fowler wrote:
> > > >>> can you truss the bad machine to see the tr read and write calls
> > > >> It isn't very illuminating I'm afraid:
> > > >
> > > > it does implicate tr
> > > > it looks like it gets the literal args 'A' '\301'
> > > > it reads " A\n" and writes " A\n"
> >
> > > I called a little C program (instead of tr) to print out argv[][]
> > > carefully, and argv[1] was the characters "A" and NUL, and argv[2] was
> > > the characters "\", "3", "0", "1" and NUL.
> >
> > > > what are your locale env var settings { LANG LC_* } ?
> >
> > > No LC_* variables are set, but LANG is "en_GB.UTF-8"
> >
> > > So if I unset LANG, tr writes "\301\n".
>
> > my guess is there is an interaction in /usr/bin/tr between some UTF-8 locale
> > and the invalid UTF-8 character '\301' which voids the A => '\301' map
> > and simply maps A => A
> >
> > it would be nice to verify this
> >
> > in any case, the original code snippet should be run with LC_ALL=C and/or
> > LANG=C
>
> Robbin Kawabata, the Sun engineer who has worked with tr and
> UTF-8 locales, is looking into this and will be replying to this thread
> on what she finds.
Robbin/April:
Any news on the issue yet ?
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
