Bug 132764

Summary:	in UTF8 mode, ncurses silently drops line-drawing characters
Product:	[Fedora] Fedora	Reporter:	Daniel Reed <djr>
Component:	ncurses	Assignee:	Eido Inoue <havill>
Status:	CLOSED WORKSFORME	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3	CC:	dickey, nalin, notting
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-09-20 15:07:53 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Daniel Reed 2004-09-16 19:22:48 UTC

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

Comment 1 Bill Nottingham 2004-09-17 17:27:59 UTC

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.)

Comment 2 Eido Inoue 2004-09-20 15:07:53 UTC

I'm getting the line characters using any *.UTF-8 locale.