Roozbeh Pournader wrote on 2001-02-14 22:11 UTC:
> I was playing with the linux console, and found that when I switch to
> USER_MAP character table, using "ESC ( K", all codes from 0x80 to 0xff can
> be displayed, but not 0x9b. It somehow behaves like its lower brother,
> 0x1b (ESC). Any explanation why only this doesn't work?
The Linux console driver was written and extended by lots of people who
very obviously were unfamiliar with both the ISO 6429 and ISO 2022
documents. That's why the parser for the ESC sequences in the
/dev/console driver is such a mess and many of the private extension
ESC sequences are not in the private extension format specified by
ISO 6429 and ISO 2022.
Recommendation: Use neither "ESC ( K" nor CSI in your application
software.
A standards conforming cleanup of the Linux console driver would be a
good thing. Throwing out all the pseudo-ISO-2022 mechanics and bolting
it down into UTF-8 mode would be even better (and prevent lots of
charset switching accidents).
If the console were permanently in UTF-8 mode, backwards compatibility
with 8-bit applications could still easily be achieved by either adding
recoding functionality to the tty or (much better!) by using on top of
the console a user-level virtual console server such as for instance the
legendary GNU screen:
http://www.gnu.org/software/screen/screen.html
Both solution have the advantage that they can also be used to do
encoding conversion if a remote terminal connected to a UTF-8 Linux box
is not capable of doing UTF-8 (and vice versa).
Markus
--
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/lists/
