Re: ISO 2022 in terminals

[Thomas Dickey]

On Thu, 3 Feb 2011, Keith Winstein wrote:

> Hello Markus and Thomas,
>
> I'm working on a UTF-8 replacement for screen-over-SSH, and was excited by 
> Markus's paragraph at http://www.cl.cam.ac.uk/~mgk25/unicode.html#term:
>
>   With UTF-8, it is not possible that your terminal remains switched to
>   strange graphics-character mode after you accidentally dumped a binary
>   file to it. This makes a terminal in UTF-8 mode much more robust than with
>   ISO 2022 and it is therefore useful to have a way of locking a terminal
>   into UTF-8 mode such that it cannot accidentally go back to the ISO
>   2022 world.
>
> Do you know what happened to this admirable idea? It seems like the major 
> terminal authors have mostly relented, and now interpret ISO 2022 shift 
> sequences again, even in a UTF-8 locale or UTF-8 mode.

xterm and ncurses are configurable.  Some places to check: vt100Graphics
resource (xterm), NCURSES_NO_UTF8_ACS (ncurses).  The defaults correspond
to the most common usage.

For the others - they're largely undocumented in this area...

> ncurses has special-cased the terminal types of "linux" and "screen" (by the 
> string in the TERM environment variable) and sends UTF-8 graphic characters 
> to those terminals ("linux" always, "screen" sometimes). But it calls those 
> terminals "broken" and sends ISO 2022 by default to everybody else.

A program which is documented to claim "vt100" compatibility and isn't,
is broken.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net