On Sat, 30 Jun 2001, Frank da Cruz wrote:
> > I was going to add the fact that telnet, rlogin, ssh etc should pass along
> > the LANG and LC_* variables like they do DISPLAY and USER but then I read
> > the other messages ...
>
> As long as we have a plethora of character sets, we have to keep control in
> the hands of the end user, i.e. the user of the client. We don't want
> various agents along the communication path making conversions based on
> guesses about the encoding or behavior of the files or applications involved.
Damn right!
My pet peeve is telnet clients that don't implement the CR-NL processing
'properly' so you can't zmodem though them; especially if the other end
only has a 94 character kermit!
If _the_user_ wanted it anti-luit would probably be run by the .profile
script like you (can) do with screen. But the LC_* variables would need
to be made available so that it's easy to setup automatically otherwise
we're back to overloading the TERM variable ... ho hum.
How about it;
should we ask Eric to add "xterm-utf-9" to the master terminfo?
> - Frank
On Sat, 30 Jun 2001, Markus Kuhn wrote:
> On Sat, 30 Jun 2001, Robert de Bath wrote:
> > I _think_ the solution might be an 'anti-luit' like program. It runs
> > UTF-8 software on an ISO-2022 terminal (probably locked to one or
> > two encodings).
>
> Try recent versions of GNU screen.
It only does iso8859-1 <-> UTF-8 and a few chars that match the acsc
string at the moment. Tho I do agree that luit should be integrated
into screen eventually.
--
Rob. (Robert de Bath <robert$ @ debath.co.uk>)
<http://www.cix.co.uk/~mayday>
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
