jw@pan.UUCP (Jamie Watson) (09/21/88)
The Informix products seem to be incapable of handling escape sequences, such as are generated by the arrow keys on ansi terminals, reliably. They are very frequently misinterpreted as ordinary input rather than as movement commands, with various unpleasant results such as fields being overwritten, input prematurely terminated, and so on. I have seen this effect on Vaxstations, Plexus and IBM RT/PC, using the Vaxstation console, the RT console, VT[12]00 terminals and IBM 3151 terminals. It doesn't seem to happen any more or less frequently with any combination of the above. jw
sullivan@vsi.UUCP (Michael T Sullivan) (09/23/88)
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. -- Michael Sullivan {uunet|attmail}!vsi!sullivan V-Systems, Inc. Santa Ana, CA sullivan@vsi.com whump, whump, whump, whump, whump, whump, whump, whump, whump, whump, whump
soley@ontenv.UUCP (Norman S. Soley) (09/25/88)
In article <860@vsi.UUCP>, sullivan@vsi.UUCP (Michael T Sullivan) 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. I'm sorry but on this one I'll probably end up agreeing with jw, this is not a solution, our users are managers and biologists and they just won't be made to understand that they should push ^j instead of down arrow, "the arrow keys are there, why can't I use them?". I had to threatean my boss (an Urban Planner by training) that I would break his fingers if he didn't keep them off the arrow keys in input mode in vi. I can somewhat sympathize with jw's perdicament with Informix's support in Europe because we wen't through a similar situation here in Canada, we bought our first copy of Informix from RDS in California and had all kind of support problems until they finally got their Canadian operation up and running (about 1 1/2 years after they first told us they were doing it next month). But is was never as bad as the problems we had when we bought it from a local VAR. However I can't agree with jw's attitude and tone, it's obvious from things he/she has said that he/she has been forced to work with Informix against his/her will and is taking it out on the product as a result. There's an old saw that goes "it's a poor workman who blames his tools". I've had very good success building applications in 4GL. It has it's warts but so does any program, and in my veiw "known bug, fixed in the next release" is the best that ANY commecial vendor has offered. The net will not solve your problems for you Jamie, the fact that Alan has stopped reponding to you is proof of this. Why not try what I did? Carefully document the bugs you have found, and make DAMN SURE they are bugs! Then make notes on every time you try to contact Informix, flag out the problems like moving offices and the American offices refusal to deal with European customers, as much as possible include exact dates and times and names of who you talked to. Then send the whole thing to the CEO of Informix Software Inc. preferably from someone in authority in your company (president or vice-president). It worked for me. -- Norman Soley - Data Communications Analyst - Ontario Ministry of the Environment UUCP: uunet!attcan!lsuc!ncrcan!ontenv!soley VOICE: +1 416 323 2623 OR: soley@ontenv.UUCP
jim@fsc2086.UUCP (Jim O'Connor) (09/26/88)
In article <860@vsi.UUCP>, sullivan@vsi.UUCP (Michael T Sullivan) 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. I will probably be echoing Jamie's opinion that this is not a very robust solution to the dilema at hand. Once users are trained and have become accustomed to the conveniences of arrow keys, weening them away is nearly impossible. ANY program which relies heavily on arrow key processing for its basic function (ala "sperform", or even something like "vi") should be expected to work correctly, given correct termcap/terminfo entries. Since I have just ordered the Informix-SQL product, I will be interested in seeing if "sperform" works realiably or not. To Jamie, thanks for the warning. --- James B. O'Connor +1 615 821 4090 x651 Filtration Sciences Corp. UUCP: uunet!fsc2086!jim 105 West 45th Street or jim@fsc2086.UUCP Chattanooga, TN 37411
jw@pan.UUCP (Jamie Watson) (09/26/88)
In article <860@vsi.UUCP> sullivan@vsi.UUCP (Michael T Sullivan) 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 <In perform the control counterparts (^h,^j,^k,^l) do <the same thing. Use these control characters, NEVER use arrow keys Yes, this is the only workaround we have found, also. Try to explain this to an end user sometime, though. It doesn't come across as a very professional product... jw
friedl@vsi.UUCP (Stephen J. Friedl) (09/26/88)
In article <806@ontenv.UUCP>, soley@ontenv.UUCP (Norman S. Soley) writes:
< ... include exact dates and times and names of who you talked to. Then
< send the whole thing to the CEO of Informix Software Inc. preferably
< from someone in authority in your company (president or
< vice-president). It worked for me.
It didn't work for us. We had some difficulties with various
branches of the Informix tree, and we wrote a non-flame letter
to the head honcho, Roger Sippl. We got no response of any kind.
--
Steve Friedl V-Systems, Inc. +1 714 545 6442 3B2-kind-of-guy
friedl@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedl
------[I'm on vacation in Ohio from 26-Sep to 10-Oct 1988]----------sullivan@vsi.UUCP (Michael T Sullivan) (09/27/88)
In article <262@fsc2086.UUCP>, jim@fsc2086.UUCP (Jim O'Connor) writes: > In article <860@vsi.UUCP>, sullivan@vsi.UUCP (Michael T Sullivan) 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. > > > > 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, > > I will probably be echoing Jamie's opinion that this is not a very robust > solution to the dilema at hand. Read my response again. I said "workaround". Sure, it would be great if sperform worked as advertised. Wouldn't it be great if everything did. However, it doesn't and in the meantime we have to use it as is. This workaround will just have to do until Informix gets it right. I hate not being able to use arrow keys and so do customers, so I'm not defending Informix. What I'm doing is giving you an alternative until that solution is found. -- Michael Sullivan {uunet|attmail}!vsi!sullivan V-Systems, Inc. Santa Ana, CA sullivan@vsi.com Just say to yourself over and over, "President Quayle". I can't do more than 2.
jkrueger@daitc.daitc.mil (Jonathan Krueger) (09/27/88)
In article <806@ontenv.UUCP> soley@ontenv.UUCP (Norman S. Soley) writes: >"it's a poor workman who blames his tools" I prefer "if all you have is a hammer, everything looks like a nail". Yes, it's silly to blame your hammer if you don't know how to use it. But it's even sillier to blame a hammer for doing a poor job of tightening screws; the solution is not to learn how to use the hammer better, it's to get a screwdriver. At the same time there are better and worse hammers, and better and worse hammering skills. But the difference between the best and worst hammer, or the best and worst hammerer, is small compared to the difference between turning screws and trying to hammer them, or hitting at nails with a screwdriver. (*) In the database world, we look to vendor products to provide tools for two distinct sets of tasks: controlling the data, and building the user interface. The relational model has helped formalize and standardize the first set, but says nothing about the second. Most vendors provide adequate toolchests for the first; quality of vendor tools for the second varies widely. At this point I have a theory that vendors who most cleanly separate the two, and who specify how each relates to the other as simply as possible, are most likely to provide good quality tools for both. -- Jon (*) Although your shop teacher's practice that you weren't going to get to use power tools until he was satisfied with your use of hand tools applies here. When I hear about "power users" I wonder how many of them are any safer with bandwidths than they would be with band saws... -- Jonathan Krueger uunet!daitc!jkrueger jkrueger@daitc.arpa (703) 998-4777 Inspected by: No. 15
allbery@ncoast.UUCP (Brandon S. Allbery) (10/03/88)
As quoted from <262@fsc2086.UUCP> by jim@fsc2086.UUCP (Jim O'Connor): +--------------- | In article <860@vsi.UUCP>, sullivan@vsi.UUCP (Michael T Sullivan) 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. | > | > 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 | | I have just ordered the Informix-SQL product, I will be interested in seeing | if "sperform" works realiably or not. +--------------- I would doubt it; the problem has existed since the old Informix product. Then again, it's also in vi and many other programs that use both ESC and function/arrow keys. The problem is handling ESC-prefixed keys while also using a bare ESC as a command; it's more Unix's fault, since a timeout is required and Unix alarm timeouts just aren't very reliable. Unify under System III/V came up with a better solution, and I believe System V curses has adopted it as well: if function keys are being used, set the packet size (VMIN) to the length of the longest function key sequence with a packet timeout depending on the baud rate and packet length. It works well, if the packet code in the driver is correct. (I've used systems where the console driver mishandled packet sizes other than 1, and the function and arrow keys NEVER worked.) Unfortunately, it's dependent on the System III/V tty driver's packet (-icanon) mode, and it can't be done with a V7 or BSD tty driver as far as I know. ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to <backbone>!sources-misc comp.sources.misc is moving off ncoast -- please do NOT send submissions direct ncoast's days are numbered -- please send mail to ncoast!system if you can help
jkrueger@daitc.daitc.mil (Jonathan Krueger) (10/03/88)
In article <12648@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >The problem is handling ESC-prefixed keys while also using a bare ESC >as a command I agree with your assessment of the problem; formally, it's an ambiguous input stream. But timing isn't a safe disambiguating method. Terminal interfaces make no guarantees about maintaining the timing characteristics of user typing. Characters that were bunched together when typed won't necessarily be bunched together when they arrive at the host. If they're meaningful either way, but mean different things, users will get unreliable and unpredictable responses to same inputs. I've seen Unify lose pretty badly when connected via networks such as TYMNET or DDN. A better solution is to remove the ambiguity. In general, function keys generate a sequence that begins with an escape. So, don't support function keys and also escape by itself as a command. But you can assign a function key to perform whatever escape used to do. Or you can support an interface that doesn't depend on function keys, and retain escape by itself as a command, useful for terminals without lots of function keys. INGRES supports both approaches. Or you can remove escape by itself as a command, use function keys where available, and support user-typed sequences that begin with escape, including longer commands that echo on a command line. GNU Emacs does this. All three methods work correctly across all communications equipment and paths, and with all UNIX (and other) terminal drivers. -- Jon -- Jonathan Krueger uunet!daitc!jkrueger jkrueger@daitc.arpa (703) 998-4777 Inspected by: No. 15
drc@wp3b01.UUCP (3964 ) (10/04/88)
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