This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problem with function keys codes with vt100 emulation


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]