Date: Wed, 16 Jan 2002 17:49:16 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Jason Evans <jasone@canonware.com> Cc: arch@freebsd.org Subject: Re: termcap versus terminfo Message-ID: <3C462D9C.D81306FD@mindspring.com> References: <20020116165926.N451@canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jason Evans wrote: > Currently, FreeBSD uses termcap for storage of terminal attributes. In > order to make this work, we have had to hack up ncurses, which is normally > based on terminfo. I have several problems with this: > > 1) It requires extra work in tracking ncurses, which is contributed source > code. > > 2) We end up having to maintain the termcap file, whereas if we were using > terminfo and submitting our changes back to the ncurses maintainer, > there would be very little divergence from the pristine contrib sources. There are tools to convert between them. Perhaps we should use them, instead? The captoinfo/infotocap/toe/tic/infocmp family of commands were written specifically for this. ESR even had his paws in a couple of them... http://www.csclub.uwaterloo.ca/u/r-ridge/ ftp://ftp.uu.net/usenet/comp.sources.unix/volume26/mytinfo/ > 3) With the likely exception of some of (but not all of) the other BSDs, I > don't think any other modern systems use termcap. Linux and SYSV-based > OSes use terminfo. In fact, Solaris does not even support the termcap > APIs. That's because these systems don't trust the users to correct their own problems, and provide binary only terminfo files, with only the compilation tools, and no decompilation tools for modifications. This is because corporate entities like to reduce support overhead, even if it means that a clued user can't fix a problem with a vendor supplied description file (or enhance it, when a new capability exists in a terminal that the vendor chose not to use, didn't know about, or a new version of a terminal ROM came out. The other benefit to termcap entries is that they can be pushed around in environments for things like SH and xterm (and are). > 4) terminfo is standardized. It is documented in SUSv2, and in all > likelihood, the Austin Group Specification (IEEE 1003.1). POSIX signals not restarting system calls by default, and the first close of an fd to a file destroying all locks, even in the presence of multiple open instances for the file in the same program are also standardized and documented in both those places. > 5) terminfo is generally better designed. termcap has scalability issues, > which we have partially solved by creating termcap.db. However, the > speedups afforded by the db file only help if using the termcap library > API, since termcap.db does not have a public API to allow direct access. > By contrast, the terminfo database is in a compiled format that is > formally documented, which allows applications to quickly access > terminfo entries without using the terminfo library API. The way you are supposed to do this is to use "tset(1)" to export the termcap entry as an envirponment variable "TERMCAP", which prevents the lookup overhead from ocurring every again: it happens once at login, and never again. Avoiding doing this correctly causing delays in running programs is not really a valid argument against termcap. If you think the design is well thought out, consider that it uses a struct, the size of which is compiled into the programs that use its version of the library, so if you want to add a new arbitrary attribute, you basically have to recompile all code that uses the damn thing, after you extend the structure to include the new element. > I've been thinking for over a month about this, trying to intuit the > rationale for sticking with termcap, and nothing really comes to mind, > except NIH. ncurses provides a compatibility shim for termcap functions, > which means that unless an application wants to access the termcap file > directly, using terminfo isn't even visible to applications. As mentioned > above, directly accessing termcap has scalability issues, unlike terminfo. Printcap? Gettytab? XXXFOOtab? > I would like to move FreeBSD to a much less hacked ncurses, which means > converting to terminfo. Are there any good reasons for not making this > change? I think the place to move the hack boundary is still inside the ncurses code. This is a problem with the ncurses code (IMO), not a problem with BSD. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C462D9C.D81306FD>