Date: Wed, 16 Jan 2002 23:41:54 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Dan Nelson <dnelson@allantgroup.com> Cc: Jason Evans <jasone@canonware.com>, arch@FreeBSD.ORG Subject: Re: termcap versus terminfo Message-ID: <3C468042.8791FBD4@mindspring.com> References: <20020116165926.N451@canonware.com> <3C462D9C.D81306FD@mindspring.com> <20020117061157.GA84018@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Dan Nelson wrote: [ ... definition of file formats ... ] > Isn't using an API better than codifying a file format? And how is an > application even going to know where the system put its terminfo files > when it decides to bypass the API? And the .05 second saved by having > the terminal description precompiled will be in the noise when we stop > caching catpages. You're actually attributing something Jason said to me, but I'll answer anyway: yes, a procedural interface is almost always better than a data interface, since it avoids things like "proc size mismatch", and the extension issue... with one exception: performance requirements constrin interface design. The precompilation is actually not the win, it's the parsing of every newline looking for a non-newline+tab combo, and a non-newline-+# combo, indicating a continuation line or a comment. After that, you have to compare every string in the set up to the delimiter for the name to see if it matches the value in the TERM environment variable. Jason was not wrong when he pointed at the overhead, it's just that there's a way around it that's not often used (and he's right that the termcap.db helps somewhat). > Another drawback with terminfo is there's no provision for > non-disk-based terminal descriptions. With termcap, a program > simulating its own termcal (screen, or emacs for example) can simply > set TERMCAP to the terminal description itself and not worry about > whether the system's termcap/terminfo is right. Same thing for telnet > and ssh. They both have the ability to pass TERMCAP to a remote > system. Handy when connecting to OSes that don't have a description > for cons25. I already noted that as one of my objections. 8-). > [...] > > 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. > > How much hacking is really involved? Every terminfo-using OS here at > work (Linux, tru64, Solaris, SCO) has a different on-disk terminfo > structure (surprise surprise), so the first thing I do is install > ncurses with the following to generate a nice /etc/termcap-friendly > lib: Basically, you have to seperate the capability lookup from the curses implementation itself. You also have to hack up the curses itself, or provide an inverse alias to two character capability string array so that the termcap lookup of values that would normally be in a terminfo database entry will be found. It's a little gross, in that the reference by name is to the address of a structure element that is parsed as a fixed length string out of the on disk structure, so you have to manufacture one of those from the termcap entry, or you have to make the interface more general (which is somewhat harder). If the string exceeds the allowed length, you have to also truncate the thing. It means that the resulting code is gross, unless it's seperated at the capability-by-name boundary, and then two sets of routines are written, along with the inverse lookup to handle the use of long names in terminfo-expecting code that uses the long name instead of the two character alias name (an incredibly cheap way to deaal with this would be to make a "long name" and "short name" entry in the database, but of course that would only work for the termcap, since the terminfo structure elements are fixed length, and ints can be too small for the names of themselves... and then, the termcap is slower than the terminfo, for the lookup; I guess you could put the entries first in the termcap database...). > I would assume that whatever things get set by these --flags are simply > #defines in a config.h file. Are there any other changes that are > needed to get a true termcap-only ncurses? You don't want that: you want both, or the possibility of either, on the same system. Perhaps the NetBSD code s the right way to go, but the ncurses code is far from knocked out (IMO). SYSV handled both by having a "termcap" library that had tgetXXX() functions, and it worked because the system default was terminfo, and short name aliases existed (and could be fit into a terminfo entery, since two characters will fit in an int, even if it's only 16 bits. 8-)). This worked by linking the termcap library before the curses library (otherwise, you got the terminfo implementations). The problem with "just doing this" is that (1) it's not BSD-like to require two libraries, or we'd already have a "libns" for the resolver, and (2) by the default being termcap instead of terminfo like SYSV, handling long names in reverse translation is a bit problematic (it works the other way because termcap-expecting code will always use the shor two cahracter names, but terminfo-expecting code could use either the short names or the longer names, and one of the reasons for the longer names in the first place was self-documentation). > If you're worried about the maintaining the source terminal description > file, you can always keep "terminfo.src" in CVS and run infotocap on it > during the build to generate a terminfo file. Nope. The problem is maintaining the modified ncurses code, not the database. THe termcap database is already well maintained, both by terminal vendors, and centrally. -- 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?3C468042.8791FBD4>