Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Mon, 8 Aug 2005 16:24:37 +0200 (MEST)
Message-Id: <200508081424.j78EObDm029821@ns-srv-2.bln1.siemens.de>
From: Thomas Wolff <towo AT computer DOT org>
To: cygwin-patches AT cygwin DOT com, cygwin AT cygwin DOT com
Subject: Re: [Patch] /etc/termcap missing eA capabilities

On Mon, Aug 08, 2005 at 01:46:13PM +0200, Corinna Vinschen wrote:
>On Aug  8 13:19, Thomas Wolff wrote:
>> 2005-08-05  Thomas Wolff  <towo AT computer DOT org>
>> 
>> 	* termcap: Updated xterm and rxvt (from /usr/share/terminfo 
>> 	using infocmp) to include the eA capability in order to enable 
>> 	programs to enable the alternate character set.
>
>Wrong mailing list.  cygwin-patches is for patches to the Cygwin package
>only.  Redirected to the cygwin ML.
I didn't see the full patch appear on the cygwin ML, just the change log.
So I guess I'll have to send it again, subscribing myself first...

Christopher Faylor wrote:
>And a hint:  Don't use termcap.  It's obsolete.
Well, at least it's not so obsolete that it shouldn't be fixed.

Let me shortly discuss this:
There are two APIs to the terminal capabilities database:
* terminfo (using tigetstr etc)
* termcap (using tgetstr etc)
Both APIs are also offered by the ncurses library, in this case termcap 
being "emulated" and also using the terminfo database.
While this is nice-to-have, I have never really understood why a program 
that really just uses either the termcap API or the terminfo API to 
handle terminal features should be forced to link with libncurses if it 
does not actually use the curses functionality.

For compatibility, not only on source level but also on makefile level, 
systems maintain an explicit library aside the ncurses library. On Sun, 
there are two identical libraries, termcap and termlib, each also 
offering both APIs (termcap and terminfo). On Linux, there is just 
termcap and it only offers the termcap API, not terminfo, which I 
don't really understand either as the terminfo API does not offer more 
functionality than the termcap API.

Advantages of maintaining the termcap API:
* Compatibility with programs that contain legacy screen control 
  (with respect to termcap vs. terminfo; I do not consider it 
  legacy to not use curses), avoiding porting effort that is 
  unnecessary because it does not gain better functionality.

Advantages of maintaining the termcap library:
* Compatibility with packages / makefiles.
* If (for any reason) some software links statically, linking with 
  ncurses just for the termcap API is overkill because it includes the 
  overhead of the unused curses functionality into the program, making 
  the executable larger - why should that be desirable?

Combining the two aspects, I would summarize:
* It is useful and important to maintain the termcap library. It would 
  be even better if it offers the terminfo API as well. It could 
  use the /usr/share/terminfo database, though, for both, making 
  the /etc/termcap database obsolete.
* It is very important, as long as the termcap library exists, to 
  keep it correct and up-to-date, and not break programs that 
  legitimately use it.

Kind regards,
Thomas Wolff

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/