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