6

I'm trying to use Curses on Fedora 12 to output status information to a VT (one of the terminals you can get to by pressing Ctrl+Alt+Fx).

When I start up my application on one of VTs ($TERM=linux) the lines for the boxes come out as the characters such as j, q, k and a few other characters. Yet when I start it within a terminal window ($TERM=xterm) everything displays as it should.

Can someone explain to me what I need to do to get the VT output to appear as the xterm? Is there a terminal setting that I can set from within my program to cause the output to be correct?

Incnis Mrsi
  • 1,958
  • 18
  • 25
Joe
  • 61
  • 1
  • 2

2 Answers2

3

A good answer would start by explaining the problem in one's own words, then selectively quote the parts which are relevant. In the ncurses FAQ section presented by @Craig, there is an aspect not detailed which helps understand the question.

Referring to the Line Graphics section of the terminfo(5) manual page, and the corresponding Line Graphics section of the curs_add(3x) manual page, the curses library has a predefined set of symbolic constants named ACS_xxxx which are drawn using similar escape sequences on various terminals.

The most common variant is based on VT100, where an application sends a special character (or escape sequence) to start the line-graphics mode and another character (or escape sequence) to end the line-graphics.

A few developers of terminal emulators objected to the notion of modes when writing text in UTF-8 mode. Never mind the irony (there are escape sequences for starting/stopping UTF-8 encoding), but ncurses has this feature to support—efficiently. To help it decide how to do line-graphics,

  • it starts with the terminal description (identified by an environment variable), which can tell only how to do VT100-style line-graphics.
  • For UTF-8, it can check the locale encoding by checking other environment variables.

If ncurses must use only UTF-8 (because the terminal does not support VT100 line graphics), it uses a built-in table of good-enough Unicode values. Drawing lines with UTF-8 is inevitably three times slower than using VT100 line-drawing, simply because three times as many characters are sent to the terminal.

All of this makes UTF-8 line-drawing an "also", not the primary focus of the library. In OP's case, something (probably locale variables) was not correct. Fedora initialized the console in UTF-8 mode, and Linux console being a well-known case which omitted VT100 line-drawing, OP got odd characters on the screen.

Since ncurses interpreted the OP's environment as supporting the capabilities in the terminal description, it switched to VT100 line-drawing mode (ignored by the console because of an overriding mode), and drew characters that it expected to map into lines. So it may have appeared on the screen like this:

lqqqqqqqqqqqqqqqk
x  Hello world  x
mqqqqqqqqqqqqqqqj

rather than

┌───────────────┐
│  Hello world  │
└───────────────┘
Thomas Dickey
  • 75,040
  • 9
  • 171
  • 268
2

From the ncurses FAQ http://invisible-island.net/ncurses/ncurses.faq.html

Line-drawing characters come out as x's and q's

The x's and q's correspond to a table (from terminfo/termcap) which tells ncurses how to map the "alternate" character set to the terminal's set of graphic characters. The reference for this table comes from the vt100. If the unmapped characters appear, then the terminal emulator does not recognize the escape sequence for switching between normal and alternate fonts that is given in the terminfo description.

There are several cases of note:

  • Terminal emulators which use a different escape sequence or different range for mapping the resulting characters. For instance the so-called vt100-compatibles such as Linux console and Tera Term.
  • Terminal emulators which are locale-sensitive. Again, Linux console is a problem area when running in UTF-8 mode, since its nominal vt100-compatibility is further lessened by ignoring the escape sequences dealing with fonts. The screen utility also has the same problem; whether to make the implementation simple or to copy the Linux console, it ignores vt100-style font switching when the locale is a UTF-8 flavor.
  • If you happen to be using Solaris, it is often configured to prefer its terminal database to ncurses, even when ncurses is installed. However, its terminal description for xterm omits the enacs which is used to enable line-drawing. This does not work well with applications such as screen and luit.

For the first case, you simply have to find the correct terminfo description. Fixing the latter is harder, since the damage is done outside ncurses. (Though one can easily make things compatible enough that this particular issue would never appear, that style of solution is not deemed proper by some coders).

The normal ncurses libraries support 8-bit characters. The ncurses library can also be configured (--enable-widec) to support wide-characters (for instance Unicode and the UTF-8 encoding). The corresponding wide-character ncursesw libraries are source-compatible with the normal applications. That is, applications must be compiled and linked against the ncursesw library.

The ncurses 5.3 release provides UTF-8 support. The special cases of Linux console and screen were addressed in development patches completed at the end of 2002.

Craig
  • 694
  • 4
  • 7