The bug seems to be in telnet (on my machine) and not in telnetd
(on the little server). The prompt telnet>, and the reaction to
the "help", is what you get when you just type telnet without
arguments.
So I looked at man telnet (which I had never done before because
it had always "just worked"). This says that entering the escape
character drops you into command mode. I never even knew that
telnet had such a thing.
The escape character is normally ^], which I had always thought
was the ASCII 'escape' character (hex 1B, or ^[). But ^] is
actually hex 1D.
The man page says that telnet is not guaranteed to be 8-bit clean.
So hex 9D might be seen as hex 1D. Sending the UTF-8 character TO
of TOKYO, which has a 9D byte in it, in fact also puts you in
command mode.
Because I never use the telnet escape character anyway, I can use
the solution provided by the man page: call telnet -E instead of
just telnet. This disables the escape character, and entering
TOKYO works fine. I'll make this an alias (and put it in my "UTF-8
on Linux" web page). Still, I think is is a bug that should be
corrected, even if telnet is old; if it says the escape character
is hex 1D, it should actually be hex 1D, and not "hex 1D or hex
9D". This is a "UTF-8 incompatibility".
Thanks to all who thought about this problem.
Regards, Jan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
