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
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".
> Cheers,
> Chris
> _______________________________________________
> ksh93-integration-discuss mailing list
> ksh93-integration-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
