Path: utzoo!dciem!nrcaer!scs!helios!uunet!wp3b01!drc
From: drc@wp3b01.UUCP (3964 )
Newsgroups: comp.databases
Subject: Re: Informix problem with escape sequences
Message-ID: <563@wp3b01.UUCP>
Date: 3 Oct 88 23:49:11 GMT
Article-I.D.: wp3b01.563
References: <483@pan.UUCP> <860@vsi.UUCP> <806@ontenv.UUCP>
Reply-To: drc@wp3b01.UUCP (Darrel Carver 914-397-4265)
Organization: AT&T -- White Plains, NY
Lines: 52

In article <806@ontenv.UUCP> soley@ontenv.UUCP (Norman S. Soley) writes:
>> In article <483@pan.UUCP>, jw@pan.UUCP (Jamie Watson) writes:
>> > 
>> > The Informix products seem to be incapable of handling escape sequences,
>> > such as are generated by the arrow keys on ansi terminals, reliably.
>> 
>> And how.  If you hit arrow keys too fast, sperform will goof up and
>> interpret and escape sequence as separate characters, thus writing a
>> possibly incomplete record.  There is an easy workaround, though.
>> Are you familiar with how h,j,k,l are used in vi?  h=left, j=down,
>> k=up, l=right.  In perform the control counterparts (^h,^j,^k,^l) do
>> the same thing.  Use these control characters, NEVER use arrow keys
>> in sperform.
[ Other comments deleted ]

This is really a example of the leading escape problem in ANSI
terminals.  The terminals are at fault, not the programs.  All
these keyboards have a escape sequence to start out thier arrow
and function keys  (for example the arrow keys are \e[A-D).  The
programs have to decide whether the key is an escape key or a function
key.

The original termcap library (used by informix -- although probably greatly
modified) tried to account for this by sleeping for one second after
the escape character was received.  If you got another character you
tried to decode a function or arrow key.  

The problem with this solution is if you have someone leaning on the
arrow keys you get weird results.  I have had programs bomb out with a
a alarm signal and dump you back to a prompt.  A real pain in the
a**.

PC applications don't have this problem.  You can lay on the arrow
keys and the program will just get a numeric code.  Unfortunately 
UNIX has to try to accomidate all those weird terminals that you can
buy.  No one package can do it gracefully.

I believe in System V Release 3 curses AT&T has tried to get around
the problem by using the VMIN timer in the termio pacakge.  However if
you use dialup at 1200 baud it still freaks out the system.  Basically
ANSI standard terminals suck for this type of application.  However
that is all you can buy now.  Possibly with the new intelligent
terminals from Sun River etc. we will get away from this problem.

Bottom line -- this is a case of a ANSI standard gone wrong that users
are stuck with.   

***** These are my opinions NOT AT&T's.  They love standards. *****
-- 
==========================================================================
Darrel Carver					AT&T Network Systems
att!wp3b01!drc or attmail!dcarver		White Plains, NY 10601