From owner-freebsd-arch@FreeBSD.ORG Fri Feb 21 20:51:11 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C325F200; Fri, 21 Feb 2014 20:51:11 +0000 (UTC) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id 836121B1C; Fri, 21 Feb 2014 20:51:11 +0000 (UTC) Received: from c122-106-144-87.carlnfd1.nsw.optusnet.com.au (c122-106-144-87.carlnfd1.nsw.optusnet.com.au [122.106.144.87]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id A6A1E3C0DCA; Sat, 22 Feb 2014 07:26:23 +1100 (EST) Date: Sat, 22 Feb 2014 07:26:22 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Peter Wemm Subject: Re: terminfo In-Reply-To: Message-ID: <20140222063006.T4103@besplex.bde.org> References: <5304A0CC.5000505@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=bpB1Wiqi c=1 sm=1 tr=0 a=p/w0leo876FR0WNmYI1KeA==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=IIIIMO1WzoMA:10 a=6I5d2MoRAAAA:8 a=DarwwxSEiXKCcQh9X7IA:9 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 Cc: FreeBSD Arch , Bryan Drewery X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 20:51:11 -0000 On Fri, 21 Feb 2014, Peter Wemm wrote: > On Wed, Feb 19, 2014 at 4:17 AM, Bryan Drewery wrote: >> Why do we not use terminfo? Our termcap is quite aged and missing a lot >> of modern terminals/clients. Using terminfo would allow us to use the >> already well maintained database from ncurses. >> >> Is it just a matter of someone doing the work or are there other reasons? > > There are historical reasons. As the person who imported the current > setup I have some insight into that. > > One issue was because cons25 / syscons was evolving. That's no longer > the case. Because things were in flux, people accumulated their own > rules. Another was that termcap was the source of truth on 4.x BSD > systems, but we could translate into terminfo dynamically for things > that needed it. At the time, the reverse wasn't adequate - the > ncurses provided terminfo wasn't rich enough to express everything we > had in termcap so we couldn't do a lossless conversion of our home > grown termcap rules into terminfo and get everything back through the > emulator. There were personal preferences as well - the ncurses > terminfo at the time was sysv-style and was a fixed binary format and > non-extensible while termcap was flexible and freely extendable. My preference is to have not stopped using 4.4BSD termcap and curses, except to simplify it a bit. NetBSD was still using 4.4-based libterm and libcurses in 2005, except to expand them a lot. > HOWEVER, if I were to do it today, I would be inclined to use netbsd's > libtinfo and cdb modules and switch to terminfo as the source of > truth. It is my understanding that netbsd's libtinfo "compiles" into > a .cdb format file and gives us the same flexibility that we have with > termcap/termcap.db without the non-extensible sysv binary format > lock-in. Then have ncurses use it instead, like netbsd does. We get > to import the ncurses sourced terminfo database and port over our > tweaks/extensions as needed. Ugh, more binary mistakes. This reminds me that I wanted to remove the .db form in ~1995. Even in 1995, you could read and parse the whole 200K termcap.src file in not very long compared with the startup time of an interactive application large enough to use termcap. But it is even better to not have a big termcap file full of support for hardware terminals that haven't been produced since 1985. This is most easily implemented (incorrectly) by copying a few fixed entries to /etc/termcap at install time. I think users have always been able to get a faster startup by copying the one entry that they use (or currently use) to ther TERMCAP environment variable or their .termcap (hopefully the implementation doesn't look elsewhere then). Bruce