> OK, but now if we are interacting with the same menu over a
> telecommunications link of some kind, the possibility for timeout
> -- and therefore a deadlock -- increases without bound, e.g. when
> the base character and the combining diaeresis go out in separate
> IP packets.
Forgive me, but this discussion seems to be endless and after all this
talk I still cannot understand what the supposed problems are.
(I understand that it is important for us to stick together and make
the world believe that we are here to solve all these `difficult'
problems, as otherwise we would all lose our jobs---but I'll make an
exception here and actually say something about this one.)
(1) "Difficulties in the design of (the equivalent of) an "expect"
script that somehow has to recognize and handle prompts."
It seems rather poor design to me to try to build Unicode
character handling into "expect." Expect was never meant to
recognize abstract characters, it is a simple mechanism to wait
for byte sequences (without any interpretation!) on a stream, and
to respond with certain actions (such as sending other byte
sequences).
Expect shouldn't try to interpret the sequences it receives, nor
the ones it sends. That's not its job, and that would be
completely useless. When writing "expect" scripts, you don't
specify sequences of (abstract) Unicode characters, but concrete
sequences of bytes, as they will be received or sent over the
line. If you look at it that way, there is no problem.
Sure, that means that an expect script will break if some crazy
operator changes the internal presentation of a prompt from using
combining characters to a precomposed one. So what? It will also
fail if the operator changes the space in "Log in" to a
non-breakable one, and anything less than full artificial
intelligence isn't going to make this problem go away.
Expect scripts are normally created by running a login session
manually, while logging the system output to a file. Later, you
use the byte sequences from the file to set up the expect
script. What these sequences "mean" is completely irrelevant to
expect. It would be counterproductive to try to add this kind of
knowledge to it (or at least I cannot see any possible benefit in
doing so).
(2) "It is not possible for an application to recognize single key
presses representing A or A+combining ring."
Let's ignore the fact that typical GUI applications don't get
their keyboard input from a stream, but get it nicely prepackaged
from a `windows' server, and let's look at a program running on a
remote machine through a terminal connection.
To take an example, let's look at a program called "vi" running on
"bigiron.ust.hk", to which I'm logged in through `ssh' from
"smalllinuxbox.ust.hk".
Now, how does "vi" distinguish me pressing the ESC key (which is
an important `command' in "vi") from me pressing the "Cursor Up"
key (which happens to generate a sequence starting with 0x1b, the
equivalent of the ESC key, and which is also a rather useful key
to press in "vi")?
You see, this is not a new problem. In fact, it has been solved
for decades. In fact, it has been solved so well that you haven't
even noticed that it has been solved before :-)
I'll leave it as homework to figure out what the solution is (yes,
I'm a teacher by profession :-)
Best wishes, and good night,
Otfried Cheong
(4 am, after uncountable bottles of beer, so forgive me if I'm not
making any sense)
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:53 EDT