So I'm running Debian sid, and Ion as my window manager.

When I launch a terminal in ion, no matter which it is (I've tried urxvt, and uxterm), the locales seem to be set right (en_US.utf8), but unicode characters show as garbage.

Then if I run another terminal from this existing one, it all works fine.

What's the catch?

http://www.linuxquestions.org/questi...a-mess-788608/

You might benefit from my thread above.

Of particular importance (from what I have learned) are two things:
1) what font you are using, and..
2) the LC_ environment variables.

Some of my terminals, I can start with my correct locale "en_US.UTF-8", but some require resetting $LC_ALL to "C" before starting the terminal, or unicode/multibyte chars are garbagy.

Tell us please, what are the unicode chars you are trying to display? What I mean is, are you trying to display another language, or are you trying to get something like what I was doing, with stuff like ncurses line-drawing chars?

Anyhow, start with a default, known-good font such as -misc-fixed, and play with your environment variables $LANG, LANGUAGES, and especially LC_ALL if the former ones don't help, before starting the terminal. You don't need to EXPORT them, just do like:

shell$ LC_ALL="blah blah" urxvt

Sasha

This is independent of any one font.

Here is the output of locale:

LANG=
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=en_US.utf8

This is even in a terminal where unicode characters are not working.

I have a simple utf-8 encoded text file, written in another language with non-ascii symbols, and the non-ascii characters are displayed as garbage.

It is not entirely independent of the font; after all, if whatever font you are using, does not have the characters in its set that you are trying to print, it simply won't work.

However, for the sake of argument, let's say for the moment that your font is fine;

1) Did you have a look at the thread I linked? Try changing your LC_ALL or LANG or LANGUAGES variables to something else before launching your terminal?

and

2) You may need to specify on the commandline (when you launch your urxvt or uxterm) what Multi-Char Font the terminal should use for the characters you desire ( in addition to the 'regular' font you are using). Also make sure your terminal is compiled with the necessary multi-byte options required for displaying these sort of characters.

Sasha

I just meant, the font is not the problem.

Why would it then display fine, when I launch another same terminal with the same font from an existing one?

As for LC_ALL, I have this in my .zshrc:

export LC_ALL="en_US.utf8"

As an experiment, let's try something:

You have the first terminal, wherein the characters are messed up, right? Inside that terminal, run the `env` command to see all the variables in play.

Now, you say that if you launch another terminal FROM the first one, the characters display correctly, right? OK, from that second terminal, run `env` command again.

Compare the outputs of the two `env` commands you ran.

% diff OLD NEW
3c3
< SHLVL=1
---
> SHLVL=2
14c14
< WINDOWID=25165830
---
> WINDOWID=33554438

Interesting. No difference.

Next experiment:

from a commandline, try:

shell$ LC_ALL="C" urxvt &

and then do, from the very same commandline:

shell$ LC_ALL="en_US.UTF-8" urxvt &

and see if one displays correctly and one does not.

Thanks for your patience! The problem definitely has to do with environment variables; it's a matter of demonstrating this, which I'm having trouble doing

Sasha

Nevermind my patience; thanks for your help

Indeed only the second one displays correctly.

OK, only the second one displays correctly.

Question: the commandshell from where you just launched those two urxvt instances, is it a LOGIN shell (interactive), or a non-interactive shell?

I ask because, if it is not a login shell, then the environment variables (and anything else) that are set up in the /etc/profile file and/or your shell's login config file .kshrc, will not be read.

To see if this is the case, do you have the option (I'm not familiar with Ion), or can you configure the launcher you are using for your terminal, to specify that the shell be a login shell? Usually this is done with an option such as -ls or -l or --loginShell when you launch the terminal.

Alternately, and easier than the above, just try sourcing your .kshrc file before trying to view the characters that are not displaying correctly, as this should do the same job, of setting the locale:

shell$ . ~/.kshrc # don't omit the period there at the start of the command; that 'period' is the 'source' command.

NOTE: I'm not 100% sure if this makes a difference, but I suggest that in your .kshrc and any other place where you define environment variables, you set the variables in two steps, like so:

LC_WHATEVER="blah"
export LC_WHATEVER

---

As a side question: How do you start your window manager? Are you using a login manager, like XDM, GDM, SLIM, or something like this, which is started by root? OR, are you booting to something like init 3, logging in as your user, and starting X with `startx`?

I have loginShell set to true in my .Xdefaults file, so it is a login shell.

I would notice if it wasnt, since I wouldn't get my fortune, which is in .zlogin

Sourceing my .zshrc file doesn't change anything, and neither does setting LC_ALL in two parts.

I use SLIM.

Hmm.. Currently I'm stumped as to what to suggest as being the "really correct fix" to this, but here's two suggestions, which you can either call them "a fix" or a "workaround" provided either one works:

1) in the /etc/X11/xinit/xinitrc file (or the comparable file on your system) put the two lines (even though they already seem to be set correctly anyway, which I don't understand) and ALSO make sure that this setting is in the /etc/profile file:

LC_ALL="en_US.UTF-8"
export LC_ALL

I would also put them in your ~/.xsession file too (yes, overkill and redundancy, but it won't hurt.. Put them everywhere!)

and (2) -- adjust the terminal launching code that your WM uses, to launch the terminal like we did above, like:
LC_ALL="en_US.UTF-8" urxvt

instead of just launching it plain and simple.

I admit to not fully being able to tell precisely what's going wrong with your setup; I was starting to pull my hair out after my own several-day ordeal with this stuff too
Maybe someone else can pin down precisely where/why the disconnect is happening for you, but unfortunately I don't know what else to suggest

PS -- after doing all/any the above, I recommend logging out, going back to init 1 and back to init <graphical> again, so all the settings and config files are read fresh.

(Matter of fact, I am currently doing the EXACT same thing with the Nano editor at this very minute: I have a unicode character in my WM's text config file, and it refuses to display correctly in Nano; I can get three different forms of garbage from it, but not the proper character! I will definitely let you know if I get it sorted out.)

Sasha

Well, it seems SLIM was my problem.

I don't know what to do with it, so I just replaced it with XDM, and now all is well.

Again thanks for your help.

No problem! But I don't know how much I may have helped...

Any clue what was wrong with SLIM, and how did replacing it solve the problem?

I'd like to know, if nobody else does, because I plan to try out SLIM at some point soon too

Does it have a config file where stuff can be edited, such as environment settings?

Cheers,

Sasha

I don't know what it was with SLIM.

XDM is just fine, I only needed SLIM back when I was frequently switching between two WMs, which XDM cant really do.