Re: Testing for UTF-8 tty mode

[Andries.Brouwer@cwi.nl]

    From: Bruno Haible <haible@ilog.fr>
    Date:   Wed, 15 Sep 1999 14:52:12 +0200 (MET DST)

    Andries Brouwer writes:

    > fprintf (f, "\030\032" "\r\357\200\240" "\033[6n\033D");
    > Simple, you said? It is terrible, dirty, wrong.
    > If there is no easy way to ask the kernel whether it is
    > in UTF8 mode, then we must add an ioctl, preferably a nice
    > generic one, so that we won't have to add one every week.

    There are two problems with an ioctl: It applies only to the console,
    not to xterm or other ttys. It is specific to Linux and will not aid
    portability of applications between Linux, FreeBSD, NetBSD and other
    Unices.

    Applications already have a way to test for UTF-8 mode: the LC_CTYPE
    environment variable.

    Another way to indicate UTF-8 tty mode would be to set the TERM
    environment variable to, say, "linux-utf8" or "xterm-utf8", and
    define a new ncurses attribute for UTF-8 mode.

    Why do we need a third way to indicate UTF-8 tty mode, specific to
    consoles?

You are thinking at a different level of abstraction.

If I say setenv LC_CTYPE=foo then that does not magically change
the keyboard input mode or the console output mode.
The only way to change keyboard input mode or console output mode
is to ask the kernel, and asking is done via an ioctl, or sometimes
via an escape sequence.
And just like everybody knows what a pain it is having to deal
with write-only registers in video cards and the like,
so is it painful if some aspects of the kernel are write-only,
that is, if you can change it, but cannot ask what the status is,
so that you cannot restore the previous state.

Andries
-
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/lists/