Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Wed, 6 Nov 2002 21:04:48 -0500
From: Christopher Faylor <cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Problem with function keys codes with vt100 emulation
Message-ID: <20021107020448.GA6188@redhat.com>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <5 DOT 1 DOT 0 DOT 14 DOT 2 DOT 20021106131511 DOT 0212e850 AT pop3 DOT cris DOT com> <00eb01c285e9$2c10ae00$b001a8c0 AT coosbayreza>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00eb01c285e9$2c10ae00$b001a8c0@coosbayreza>
User-Agent: Mutt/1.5.1i

On Wed, Nov 06, 2002 at 03:06:43PM -0800, Reza Roodsari 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.

There is absolutely nothing broken here.  This is how things work.
Cygwin emulates the 'cygwin' term type.  That's how it works.  That's
how you should expect it to work.  There aren't a bunch terminal
emulations built into cygwin.  There is just one terminal emulation.

Really.  Think about it for a minute.  How complicated would cygwin be if
you could just set an environment variable and have it emulate whatever
you set it to?

>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).

"Knowing how" is cygwin is programmed in C++.  The program is meant to emulate
only one thing.  Ditto (sort of) for rxvt, although it may have slightly more
flexibility.

>Does this mean that /etc/termcap is not used at all?

No.

>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?

Cygwin doesn't read /etc/termcap.  *Programs* read /etc/termcap.  You set
your TERM to cygwin and then functions in libtermcap.a or libncurses know
how to control the screen via cygwin.

Think of cygwin as an Italian taxi driver named "Antonio".  You can talk
to Antonio in Italian and he'll respond.  Renaming Antonio to "Hank
Hill" won't mean that he'll be a native English speaker with a Texan
drawl.

Similarly, if you want to send characters to cygwin to tell it to clear
the screen, you need to use the correct characters.  You can't just say
to cygwin "Ok, you're a vt500 now" and expect it to magically understand
everything about a vt500.

>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.

captoinfo does seem to be misbehaving but I don't see why you need it.  The
terminfo database should already be populated on your system.

cgf

--
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/