<<< Date Index >>>     <<< Thread Index >>>

Re: [OT] ncursesw and UTF-8



On Mon, Nov 03, 2003 at 10:00:00AM +0100, Andrei A. Voropaev wrote:

> On Sat, Nov 01, 2003 at 08:42:05PM -0500, David Yitzchak Cohen wrote:
> > On Sat, Nov 01, 2003 at 06:42:57PM -0500, Thomas Dickey wrote:
> > 
> > > probably.  I see some occasional comments to the effect that there are
> > > patches to make bash work properly with UTF-8, which implies that it
> > > does not.
> > 
> > bash most certainly does NOT work well with UTF.  Here's my .inputrc,
> > along with a comment at the end venting some of my frustration:
> 
> Actually it works fine. It just also has to be linked to support wide
> chars. Just mutt has to be linked against ncursesw.

Okay, then let me correct myself: bash most certainly does NOT work well
with UTF without rebuilding from source ... which means my frustration
still need venting. . .

> > #For some reason, when I type international characters, they still appear 
> > like
> > # weird backslashed numbers, but at least readline doesn't reject them, and 
> > they
> > # look like what they're supposed to when they come out the other end ;-)
> 
> This is result of bad setup with locale.

My locale is setup as LC_ALL, LANG, and LC_CTYPE all set to es_ES.UTF-8
everywhere, running on a UTFed console ... and it works fine for many
programs - including my own (which use gettext).  In fact, the messages
are internationalized even in bash itself (albeit 8859-1, not UTF -
perhaps the note you made below applies here).  However, when I type an
á for instance, it appears as \303\241 instead (although the resulting
message when I try to execute it comes out correctly as "bash: á:
command not found").  Bash seems unique in this regard, as every other
program I can think of off-hand that I use has no trouble outputting
the actual characters I type.

> In my case I make sure that
> there's absolutely no LC_ and no LANG variables in my enviroment.

Neither of those hurts to have if you never switch locales.

> Then I
> start xterm with the following command line
> 
> LC_CTYPE=en_GB.UTF-8 xterm  -fn 
> '-misc-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-iso10646-1'

Consoles don't need any of that fancy gunk ;-P

> In this case I don't even use special .inputrc and get all international
> characters displayed correctly (if they are written as UTF-8 of course
> :)

Oooooh ... I want, too :-(

> And of course it's worth mentioning that en_GB.UTF-8 locale was not
> available originally in my distribution so I had to create it using
> localedef program. Note that since this locale is UTF-8 you don't really
> care if it is en_GB or de_DE or whatever.

Do you happen to have the commandline available off-hand?  If not,
I'll just look it up; but if yes, you can save me some time.

Thanks,
 - Dave

-- 
Uncle Cosmo, why do they call this a word processor?
It's simple, Skyler.  You've seen what food processors do to food, right?

Please visit this link:
http://rotter.net/israel

Attachment: pgpzz04elYCl4.pgp
Description: PGP signature