Usando curses com o console do Linux

Question

Estou tentando usar o Curses no Fedora 12 para enviar informações de status para um VT (um dos terminais que você pode acessar pressionando Ctrl + Alt + < kbd> Fx ).

Quando inicio meu aplicativo em um dos VTs ( $TERM=linux ), as linhas das caixas saem como caracteres como j , q , k e alguns outros caracteres. No entanto, quando eu inicio dentro de uma janela de terminal ( $TERM=xterm ), tudo é exibido como deveria.

Alguém pode me explicar o que preciso fazer para que a saída do VT apareça como xterm? Existe uma configuração de terminal que eu possa definir a partir do meu programa para que a saída esteja correta?

    

Answer 1

Do ncurses FAQ link

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.

    

Answer 2

Uma boa resposta começaria explicando o problema com as próprias palavras e, então, citando seletivamente as partes que são relevantes. Na seção de perguntas frequentes sobre ncurses apresentada pela @Craig, há um aspecto não detalhado que ajuda a entender a pergunta.

Referindo-se à seção Gráficos de linha da página de manual terminfo (5) , e a correspondente Gráficos de Linhas seção do curs_add (3x) página de manual, a biblioteca de curses tem um conjunto predefinido de constantes simbólicas chamado ACS _ xxxx que são desenhadas usando seqüências de escape similares vários terminais.

A variante mais comum é baseada no VT100, onde um aplicativo envia um caractere especial (ou sequência de escape) para iniciar o modo de linha de gráficos e outro caractere (ou seqüência de escape) para terminar a linha -gráficos.

Alguns desenvolvedores de emuladores de terminal se opuseram à noção de modos ao escrever texto no modo UTF-8. Não importa a ironia (existem seqüências de escape para iniciar / parar a codificação UTF-8), mas ncurses tem esse recurso para suportar - de forma eficiente. Para ajudar a decidir como fazer gráficos de linhas,

• começa com a descrição do terminal (identificada por uma variável de ambiente), que pode informar apenas como fazer gráficos de linhas no estilo VT100.
• Para UTF-8, ele pode verificar a codificação de localidade verificando outras variáveis de ambiente.

Se ncurses precisar usar apenas UTF-8 (porque o terminal não suporta gráficos de linha VT100), ele usa uma tabela interna de valores Unicode bons o suficiente. Desenhar linhas com UTF-8 é inevitavelmente três vezes mais lento do que usar o desenho de linha do VT100, simplesmente porque três vezes mais caracteres são enviados para o terminal.

Tudo isso torna o desenho de linhas UTF-8 um "também", não o foco principal da biblioteca. No caso do OP, algo (provavelmente variáveis locais) não estava correto. O Fedora inicializou o console no modo UTF-8, e o console Linux sendo um caso bem conhecido que omitia o desenho de linha do VT100, o OP tinha caracteres estranhos na tela.

Como ncurses interpretou o ambiente do OP como suportando os recursos na descrição do terminal, ele alternou para o modo de desenho de linha do VT100 (ignorado pelo console devido a um modo de substituição) e desenhou caracteres que ele esperava mapear em linhas. Então pode ter aparecido na tela assim:

lqqqqqqqqqqqqqqqk
x  Hello world  x
mqqqqqqqqqqqqqqqj 

em vez de

┌───────────────┐
│  Hello world  │
└───────────────┘