Glenn Fowler wrote: > > some users have reported problems with ksh93 vs UTF-8 locales > in particular garbage characters being emitted in ksh vi or emacs edit mode
The last report was about Linux/x86 in interactive mode (non-interactive processing of multibyte characters works, too) - right now (ast-ksh.20061207) it is working perfectly on Solaris/SPARC and Solaris/x86 which means this is a platform-specific hiccup while the multibyte code itself is Ok (even with ja_JP.PCK&&zh_CN.GB18030). > to date the reports have been anecdotal > my (and dgk's) efforts to reproduce the problems have failed > possibly due to improper xterm/os/env setup on my part What exactly do you miss as development environment ? Just keyboards or a machine which has the locales installed or what do you need ? > I'd like to either capture ksh in the act or debunk the anecdotes > so that the integration sources can be finalized for this round Agreed. > if anyone has seen this behavior with LC_ALL=en_US.UTF-8 and > a true UTF-8 terminal could you please trace/strace/truss > ksh reading the utf-8 chars in and then printing them out > e.g., capture the ksh93 process read/write syscalls (with > expanded buffer/size data) for a command like > > echo ascii<utf-8-char-sequence>ascii > > my guess is that the reported bad behavior is caused by invalid > UTF-8 character input (garbage in) and not a bug with ksh' multibyte > char processing -- provide a trace to prove me wrong I'll try to post that later today... AFAIK the problem is a bug in ksh93 because bash works OK in the same setup while ksh fails to handle the '????' characters in my case (on Linux/x86, Solaris is Ok). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
