À 07:10 1999-09-28 -0700, Frank da Cruz a écrit :
>In interactive telecommunications, we have the following situation:
>
> 1. Host sends "login:" (or any other prompt).
> 2. User is supposed to type her ID (or any other response).
>
>When using Unicode, the terminal emulator may not print the final character
>of the prompt because it doesn't know yet whether any combining characters
>will follow.
There is no good reason for the terminal not to print the final character
when received. If a combining character comes later, the terminal simply
has to redisplay the combination over the previous glyph. This is what our
Arabic terminals and emulators have been doing for years (e.g. receive an
Arabic letter and display it in final form; receive another letter,
redisplay the previous one in middle form and the new one in final form).
>If the process is being executed by a script, the script sits and waits;
>"waitfor 'login:'" will not succeed, since it can not be known whether
>'login:' has arrived until the next base character after ':' comes, but no
>such character is coming (I realize it is silly to expect a colon to have an
>accent but those are the rules -- and not all prompts end with colon).
>
>There is no escape from this situation other than introduction of a "higher
>level protocol" to signal "ok, I'm finished transmitting, now it's your
>turn", just like in the old half-duplex days.
Well, it seems to me that the login protocol *is* a higher level protocol
w/r Unicode. If the protocol says that "login:" is to be acted upon, I
don't see why the terminal-side script couldn't act on it without waiting
for eventual combining characters that won't be coming. There's no use in
waiting for the next base character, the triggering string has been received.
-- François Yergeau
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:53 EDT