Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.misc -> Re: ISO VT320 emulator with key-bindings for Oracle Forms

Re: ISO VT320 emulator with key-bindings for Oracle Forms

From: Frank da Cruz <fdc_at_watsun.cc.columbia.edu>
Date: 8 Jun 1999 19:56:28 GMT
Message-ID: <7jjshc$ere$1@newsmaster.cc.columbia.edu>


> Frank da Cruz wrote:
> > Scott G. Hall <Scott.Hall_at_GSC.GTE.Com> wrote:
> > : "Richard S. Shuford" wrote:
> > : > "Frampton Steve R" wrote:
> > : > > I'm in need of a VT320 emulator with key-bindings for Oracle
> > : > > SQL*Forms; it needs to either run under Linux/Unix or [in dosemu].
> > : >
> > : > Keep in mind that character-cell terminals communicate their
> > : > keystrokes by means of Escape sequences, as opposed to scan codes.
> > :
> > : There is another regular poster to this newsgroup who is the author of
> > : Kermit-95. I believe that he emulates the VT-220 function keys correctly
> > : so that it would work for you. Let's hope he is reading this now, and
> > : can reply if he has a version for UNIX.
> >
> > Sorry, we can't make terminal emulators for UNIX as we do for DOS and
> > Windows, since in UNIX we do not have direct access to the keyboard and
> > screen. How is a UNIX application supposed to know that you pushed F7 on
> > your keyboard, or Ctrl-F8, or Alt-Right-Arrow, etc? It usually doesn't
> > even know what kind of keyboard you have.
>
> Standard terminfo stuff. The program "cu" in the UUCP package is an example
> of a terminal emulator...

>
If cu is a terminal emulator, so is C-Kermit, and so are UNIX telnet and rlogin. But none of these are really terminal emulators -- they are transparent communication pipes that give you a terminal session.

> A remapping terminal emulator would act just like cu, but when it gets the
> characters from the terminal, if it receives the "Esc" character (or
> whatever escape code defined by its term type in the terminfo capabilities
> database) it checks for what capability the next several characters match.
>
Yes, we know this, but the situation is far, FAR more complex than that. Try writing a communication program for UNIX that is:

  1. Portable to many UNIX varieties;
  2. Portable to assorted communication methods;
  3. Works on the console, in remote sessions, and in xterm windows.

Factor in that curses/termcap/terminfo libraries are:

  1. Buggy;
  2. Inconsistent among different UNIX platforms and versions (e.g. the APIs differ -- even a simple function like tputs() has practically infinite combinations of return type and argument types, thus preventing any program that uses it from being portable without including hundreds of #ifdefs);
  3. Dependent on buggy and/or incomplete databases;
  4. Offer only an incomplete and sketchy model of any real terminal, not even close to sufficient for defining an accurate emulation;
  5. Notorious for refusing to work due to library version mismatches;
  6. Sometimes not available at all.

And that in any case, this does not solve the original problem:

  How do I map Shift-Alt-F7 to such-and-such a function?

The answer will still be: "you can't, because the software has no way of knowing that you pressed Shift-Alt-F7".  

Furthermore, even when we give up on discovering what key the user actually pressed and follow the termcap/terminfo escape-sequence model, we still have the age-old problem of distinguishing the case where the user types the Esc key and then some other keys (as s/he might do when using EMACS) from the case where an escape sequence is generated by curses. And no, we can't rely on timings to distinguish these two cases because there is no guarantee, in the general case, that a curses-generated escape sequence won't be broken into separate IP packets that are routed in opposite directions around the world.

If it was easy (or even possible) to write terminal emulators for UNIX, we'd have as many of them already floating around as we do for DOS and Windows. After all UNIX has been with us since before 1970 -- long before DOS *or* Windows.

Received on Tue Jun 08 1999 - 14:56:28 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US