From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040809 Epiphany/1.3.8 Description of problem: In the Linux console, with $LANG set to en_US.UTF-8, and /etc/sysconfig/i18n set to the FC3t2 default of: LANG="en_US.UTF-8" SUPPORTED="en_US.UTF-8:en_US:en:de_DE.UTF-8:de_DE:de:ga_IE.UTF-8:ga_IE:ga" SYSFONT="latarcyrheb-sun16" (The extra entries in SUPPORTED are related to additional language packs I have installed; the same behavior exists even if only the en* entries are present.) ncurses programs like alsamix (which we ship) or naim behave irratically in mixed UTF8/non-UTF8 environments. For example, run: alsamix and compare with: env LANG=en_US alsamix With LANG set to the correct en_US.UTF-8 value, alsamix uses +-| in place of true line-drawing characters. This is the expected behavior when line-drawing characters are not available. With LANG set to the incorrect en_US.UTF-8 value, alsamix displays *nothing* in place of the line-drawing characters. I do not mean blank spaces, I mean nothing: The characters do not appear in any form at all. This causes placement to break (not the relative positions of the word "Mic1" and "Mix" in the two views) and other undesirable screen artifacts. This can be reproduced the same way using the "dialog" program, which links against libncursesw.so (as opposed to libncurses.so). Compare: dialog --yesno test 0 0 against: env LANG=en_US dialog --yesno test 0 0 Another way to reproduce this issue is to start a program inside screen in a non-UTF8 environment (where $LANG is correctly en_US), then resume the session (screen -r) from within a UTF8 environment (where $LANG is correctly set en_US.UTF-8). The same problem appears: Line-drawing characters simply are not rendered on the screen. As another data point: Mixed UTF8/non-UTF8 in a gnome-terminal instead of the Linux console works to a full degree: The line-drawing characters are displayed properly to the terminal. This may imply that ncurses is passing along line-drawing characters unmodified in UTF8 and the Linux console driver is the component responsible for dropping them from view. I do not know which component (ncurses or the Linux kernel) is "at fault" if this is the case. Version-Release number of selected component (if applicable): ncurses-5.4-13 How reproducible: Always
I'm assuming your second situation intends: With LANG set to the incorrect en_US value... Note that there are line-drawing characters in UTF-8; not sure why it wouldn't be using them. As for running in en_US, that means it will output non-UTF-8 line drawing characters - when the console is in UTF-8 mode, those are unprintable. So it's more or less expected. (You can run unicode_stop to switch the console mode.)
I'm getting the line characters using any *.UTF-8 locale.