Table of Contents
Getting output working in EPIC5
If you are in a hurry, skip to the bottom of the file for a list of problems and solutions. Or you can read everything to understand why problems happen.
Getting EPIC to handle your keypresses and output correctly requires the participation of every program between you and EPIC.
Your terminal emulator (Putty, xterm, App.Term, KTerm)
To your terminal emulator, the only thing that matters is whether you are using UTF-8 or not; and if not, what font you're using. If you can turn UTF-8 on, do it. If you can't, you must know what encoding your font is for. Many times the encoding is in the font name. Common encodings are ISO8859-15, KOI8-R, or CP437.
Your remote login shell
You have to tell your remote login shell what encoding you are using. In Unix, this is done with locales. You can see what locales are available with
You set your locale with the LC_ALL environment variable. You want to choose one that looks like “<language>_<country>.<encoding>”, ie, “export LC_ALL=en_US.UTF-8”. The most important thing to make sure the <encoding> part agrees with your terminal emulator!
Your multiplexer (GNU Screen)
BEFORE you started GNU Screen the first time, you remembered to set LC_ALL, right? GNU Screen will translate your input from the original LC_ALL locale to whatever encoding you specify in each window. You want to make sure that GNU Screen is using UTF-8 in all of its windows.
There are three ways to do this.
1. Put “defutf8 on” in your ~/.screenrc. This tells GNU Screen to assume every program you run under it is using UTF-8. This is dangerous because not every program supports UTF-8. When you do this, make sure EACH AND EVERY SHELL sets the LC_ALL environment variable to “en_US.UTF-8” or any appropriate UTF-8 encoding.
2. Within your EPIC window, do control-A then :info and you should see something like
(27,80)/(80,80)+100 +flow -c1 **UTF-8** 6(zsh)
(27,80)/(80,80)+100 +flow -c1 **G0[BBBB]** 6(zsh)
If you see the first, then you are in UTF-8 mode. If you see the second, you can turn on UTF-8 with control-A then :utf8 on. Don't forget to set LC_ALL to an appropriate UTF-8 locale!
3. Tell EPIC what (non-utf8) locale you are using. If you can't use UTF-8, then make sure your LC_ALL environment variable is set to something appropriate for your encoding, like “export LC_ALL=en_US.ISO8859-1”.
Remember – if GNU Screen and EPIC do not agree on whether you are using UTF-8, then things are going to get screwed up. If GNU Screen and your terminal emulator do not agree on using UTF-8, things are going to get screwed up.
COMMON PROBLEMS (and solutions)
Problem 1: When you type non-English characters the input line gets corrupted (you don't see characters, the cursor doesn't move)
Cause: GNU Screen and EPIC do not agree on whether you are using UTF-8.
Solution: Make sure GNU Screen is set to UTF-8 mode and make sure your LC_ALL environment variable is correctly set before you start EPIC.
Problem 2: EPIC says "Your /ENCODING CONSOLE is <something> which is wrong."
Cause: You either didn't set a locale (EPIC assumes you are using ISO8859-1 if you don't set your locale) and you are using UTF-8, or you set a UTF-8 locale, but aren't typing in UTF-8
Solution: If you didn't set a locale (LC_ALL), set it. If you did set LC_ALL, make sure GNU Screen agrees with LC_ALL about whether you are using UTF-8 or not.
Problem 3: EPIC says "Your /ENCODING CONSOLE is <something> but you seem to be typing UTF-8."
Cause: You probably didn't set a locale (EPIC assumes you are typing ISO8859-1 if you don't set your locale) and you are using UTF-8.
Solution: Set your LC_ALL environment variable to an appropriate UTF-8 locale before you start EPIC.
Problem 4: I set my LC_ALL but EPIC still says I'm typing UTF-8.
Cause: GNU Screen does NOT set LC_ALL on inside shells.
Solution: You have to set LC_ALL before you start GNU Screen and again a second time afterwards. If you don't set LC_ALL on inside shells, EPIC will assume you're not using a locale and defaults to ISO-8859-1.
Problem 5: EPIC says that my locale isn't acceptable
Cause: Locale names are specific to each operating system, so you might have spelled it wrong.
Solution: Use the “locale -a” command to see your system's valid LC_ALL values. Choose an appropriate one.