Red Hat Bugzilla – Bug 75430
Accented characters and the like in utf8 console
Last modified: 2007-11-30 17:10:30 EST
Description of Problem:
When using the console with a utf8 locale I cannot use accented characters.
Additionally, when using characters like ç I have to press backspace
twice to delete them. The first backspace press eliminates the character
from screen but if I try to run something, i.e. ls, it fails. This is not
the whole story, backspacing those characters also erases part of the bash
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. try to use an accented character (eg. á)
2. press ç twice
3. backspace until console beep
no character appears after step 1
after 3 the bash prompt is partially erased
It shou work like in 7.3
I tested this using en_US.UTF-8 and pt_PT.UTF-8 locales
I have a very similar problem with ru_RU.utf8 .
I have also noticed something strange while trying to fix the problem. In
/etc/profile.d/lang.sh matching for utf is done this way:
case $LANG in
while with my poor understanding of this I would expect something like:
case $LANG in
case $LANG in
or evencase $LANG in
I am not insisting though :)
accented characters (and cyrillic) in utf-8 are two bytes long, compared to one
byte in latin-* and koi8. The "needing to backspace more than once to erase a
char" is not a kbd issue, but rather an I18N issue with whatever shell you are
The need to backspace more than once was a sidenote and it is now fixed in
bash-2.05b-7. The main issue was that I couldn't use accented characters with an
utf8 locale, and I still can't.
while in the console, please tell me the locale you're running in (type
"locale"), the keymap you have loaded, whether you are in unicode mode or not,
and the scancodes that are generated when you press the keys (type "showkey")
This is the output of "locale" (note that the problem reported also happens with
a full en_US.UTF-8 or pt_PT.UTF-8 locale):
My /etc/sysconfig/keyboard file contains this:
I am using unicode.
The scancodes generated for some accented characters are for example:
ã -> 43,30 ("tilde", "a")
á -> 27,30 ("acute", "a")
à -> 42,27,30 ("shift", "grave", "a")
Additionally my /etc/sysconfig/i18n file contains:
In Red Hat 9 I still can't use accented characters on the console.
In the kernel there is no tranlsation from 8bit character value
found in the compose key translation table to utf-8 characers.
It is easy to add that, but that would work only for latin1
characters and fail misserably for other characters, especially
If you trap the output that is actualy produced by the compose sequences
you will see that you actualy get valid 8bit non-utf8 characters, which the
console will refuse to display if it is un unicode mode.
non-ASCII input into the console won't be supported on UTF-8 based systems (RHL
8+) until the kernel supports it. See the release notes in the next beta for
more info. Of course, input through X will always be supported.
unfortunately FC2 still has this problem... which is bad news for
those who want to write in their native language using the console...
Some of us still like using the console, it is unfortunate that is is
I think I am experiencing the same problem...
Fedora Core 3
I have "echo SÃ£o_Paulo" written at the terminal prompt. (SÃ£o as I see
it right now is S, a with a tilde above it, and then o.) If I scroll
all the way to the left using the left arrow key, and then scroll back
to the right, the command will be re-written, shifted one character to
the left, one character at a time as I hit the right arrow key. As I
am scrolling left, the cursor actually appears to skip the Ã£
(a-tilde). The situation gets much worse if I try to delete
characters to the left of the Ã£ (a-tilde). I'm not sure what encoding
the original source of the text used; LANG and all LC_* vars are set to en_US.UTF-8,
Terminal -> Set Character Encoding is set to Current Locale (UTF-8),
and the letter does display correctly as an a-tilde in my terminal.
Christopher, that is a bug in your shell, unrelated to the rest of this report.
The original bug is caused by missing compose support for UTF-8 in the kernel,
tracked in bug 143014.
*** This bug has been marked as a duplicate of 143014 ***