Problem with function keys codes with vt100 emulation

Randall R Schulz rrschulz@cris.com
Wed Nov 6 16:49:00 GMT 2002


Reza,

The terminal emulation available under Cygwin is not programmable, so it's 
up to the software to adapt to it, not vice versa.

I'll reiterate one more time: TERM does not affect how key sequences are 
generated or how escape sequences are interpreted. Termcap and terminfo 
_describe_ terminals and terminal emulators they _do not_ modify or control 
the operation of terminals and / or emulators.

If you're running software that assumes it's interacting with a stock VT100 
(and if none of the Cygwin emulators can match that standard sufficiently 
closely), then you're out of luck.

Furthermore, if you have such software, then no amount of TERM, termcap or 
terminfo manipulation is going to solve the problem.

If that's the case and you're between a rock and a hard place, you may want 
to consider modifying either the software you need to use or one of the 
Cygwin emulators. I think the console emulator is built in to the Cygwin 
"kernel" (Cygwin1.dll), so you'd probably want to work with RXVT or if 
you're using or willing to use X, an X-based emulator (xterm has been 
ported to Cygwin).

Before you go to that length, however, look at the manual pages for RXVT 
and xterm. As is typical for X11-based applications, they're highly 
configurable. I see some options in the manual pages for these applications 
that suggest you might have some wiggle room to get things working.

Lastly, there might be another X-based terminal emulator out there that has 
the kind of key sequence configurability you need. You might have to do 
some porting to make it work with Cygwin.

Good luck.

Randall Schulz
Mountain View, CA USA


At 16:33 2002-11-06, Reza Roodsari wrote:
>Hi Randall,
>
>Thanks once again and in response to your question as to why I am trying to
>chang TERM, it is because I need it to generate \EOP for pressing f1 and
>\EOQ for pressing f2.  This is the reason why I got into this.  These key
>sequences are what is produced when I use other telnet clients (such as
>hyperterm on windows) using ansi or vt100 terminal emulation.  But the
>cygwin console generates \E[[A and \E[[B even when TERM is set to vt100.
>Given what is in the /etc/termcap file this is clearly wrong.
>
>That's all I really am asking about.  Either my understanding is wrong and
>the cygwin console should generate \E[[A for f1 eventhough TERM is set to
>vt100, in which case it would be nice to know what the role of /etc/termcap
>is.  Or there really is a bug and all I need then is a workaround.
>
>Regards,
>
>Reza
>
>----- Original Message -----
>From: "Randall R Schulz" <rrschulz@cris.com>
>To: <cygwin@cygwin.com>
>Sent: Wednesday, November 06, 2002 3:31 PM
>Subject: Re: Problem with function keys codes with vt100 emulation
>
>
> > Reza,
> >
> > The TERM variable is most certainly _not_ broken. You're misunderstanding
> > what it's for. The TERM variable is how programs that must adapt to
> > different terminal types (emulators or physical hardware) find out how to
> > properly drive the terminal's display and respond to characters sent by
>it.
> >
> > Some applications use termcap, others use compiled terminfo. They're
> > conceptually the same thing (hence the possibility for a utility like
> > "captoinfo"). They simply are a way to capture the details of how software
> > should interact with a terminal (or a terminal emulator).
> >
> > There are many terminals out there (I think--I haven't seen one for years
> > now) and they all use distinct control sequences and produce distinct key
> > sequences. That's why one needs something like termcap or terminfo.
> >
> > Beyond curiosity, which is fine, there's no need for you to know the
> > details of the design and operation of a terminal emulator (any more than
>
> > you need to know how a hardware terminal works, as long as it does
>work...).
> >
> > I'm not sure you actually have a problem, do you? Any program that uses
> > either termcap or terminfo (correctly) should work under Cygwin as long as
> > the TERM variable is set properly. Why are you trying to change TERM? Just
> > leave it the way Cygwin initializes it and you should be fine.
> >
> > As I said, I don't know anything about captoinfo, so I can't help you with
> > it. Have you read its man page?
> >
> > Randall Schulz
> > Mountain View, CA USA
> >
> >
> > At 15:06 2002-11-06, you wrote:
> > >Randall, thanks for the quick response.
> > >
> > >So the TERM environment variable is somewhat broken, in that setting it
>to
> > >something else is a no-op.  The first question that comes to mind is
>whether
> > >this is characterized as a bug or a feature, and if a bug how deep does
>it
> > >run, and how likely that it will ever be fixed.
> > >
> > >On the issue of 3 terminal emulation models (cygwin console, RXVT, and
> > >xterm) I am a bit lost.  Forgive me for being slow here, but if I
>understand
> > >you correctly the terminal emulation model is hard-coded into these
> > >applications (knowing how would be nice).  Does this mean that
>/etc/termcap
> > >is not used at all?  For example, if I change the termcap entry for linux
> > >(cygwin inherits from linux) to generate vt100 function key codes then
>will
> > >I get \EOP for f1 in the cygwin console?
> > >
> > >Is there any reference materials I can read to bring myself up to date on
> > >the architectural issues/shortcomings here?
> > >
> > >On the problem with captoinfo the issue is that it prints nothing (other
> > >than errors) to stdout.  I have captured the output of "captoinfo
> > >/etc/termcap" and "captoinfo -V /etc/termcap" in the two attached file
>for
> > >your reference.  As I said before, considering the findings so far, this
>is
> > >probably unrelated to the topic of the discussion.
> > >
> > >Thanks again,
> > >
> > >Reza
> >
> >
> > --
> > Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> > Bug reporting:         http://cygwin.com/bugs.html
> > Documentation:         http://cygwin.com/docs.html
> > FAQ:                   http://cygwin.com/faq/
> >
> >
>
>
>--
>Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>Bug reporting:         http://cygwin.com/bugs.html
>Documentation:         http://cygwin.com/docs.html
>FAQ:                   http://cygwin.com/faq/


Randy 


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/



More information about the Cygwin mailing list