Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cs.utexas.edu!ut-emx!mybest!moray!uhnix1!sugar!ficc!peter From: peter@ficc.uu.net (Peter da Silva) Newsgroups: comp.unix.wizards Subject: Re: terminfo Keywords: terminfo, curses Message-ID: <1536@ficc.uu.net> Date: 19 Sep 88 15:23:48 GMT References: <508@altos86.UUCP> <10544@ulysses.homer.nj.att.com> <1389@zen.co.uk> <3194@pegasus.UUCP> Organization: SCADA Lines: 98 In article <3194@pegasus.UUCP>, hansen@pegasus.UUCP (Tony L. Hansen) writes: > <> = me > < Nonsense. I wrote a termcap emulation for CP/M in 1981 that supported long > < names. I didn't actually time it, but since the code I wrote did a strcmp > < type search (abort as soon as a match fails) it might even be faster than > < a two-byte match (which is what you seem to be implying termcap does). > A two byte match done with && is considerably faster than calling strcmp(). > Both abort as soon as a match fails and the first is done without the > overhead of a function call. I didn't say I called 'strcmp', I said I did a strcmp-type search. In fact I had the little loop sitting there so I could just keep stepping on through the table when the search failed. > Parsing the data file is not the only problem with termcap, however. The > algorithm for searching for a given capability, after having parsed the > entire entry into memory, is an n^2 algorithm. Of course you could sort it, hash it, make it into a tree, and so on. There's nothing that says termlib has to do a linear search. > The search for each > capability starts over again at the very beginning of the entry. Given that > curses pulls in a large majority of the boolean, numeric and string > capabilities, this searching for all of the capabilities overshadows the > parsing of the data file. Then curses is written badly. The best way to do this is to step through the data and poke stuff into a statically compiled binary tree (or hash table or whatever) of the capabilities you need. In fact, if you use a hash table you can probably gen up a near-optimal hash function for it, since you know the data space. > This was all reported in the 1982 Usenix proceedings. Sorry, I missed the 1982 Usenix. Still, there is plenty of room to speed up termlib without changing to a completely different system. See above for ideas. It's a bit late now, but surely you can understand the difference between design problems and implementation problems, > Here is chgtinfo.sh: [script omitted] > This is both quick and easy. Especially under System V release 3 where tic > is 3 to 10 times faster than the System V release 2 version of tic. Bleah. Leaving little surds in the file system is a good thing? > And how do you usually edit your environment variable TERMCAP? Unless you > have the ksh, you usually have to type it all in, do it via a separate > program, or writing the variable to a temp file and using an editor such as > vi on that temp file, then read the temp file back into your environment. Generally the latter. I often just stick my captive TERMINFO in my .login, in a switch. Then I can mail it around all over the place. > < 10) Use the terminfo routines in other environments. I can define a > < gamecap file and use the termcap routines to access it. The entries in > < there don't have to have anything to do with terminals. > I agree that the routines could be made usable in other environments. I > believe that your use of the termcap routines for gamecap would require > either having the source avaiable or doing various tricks with the > environment. All you have to do is point 'tent' to your new table, diddle it, and point it back again. > Actually, better yet would be a standard set of database routines available > on all systems. Yeh, that'd be nice too. > < 11) Use standard UNIX tools on a terminfo file. What's the quickest way to > < get a listing of all the terminals supported under terminfo? I don't know > < any easy ones. > The quickest way that I know of is: > ls -C /usr/lib/terminfo/? Doesn't give you the full names of the terminals. Doesn't tell you what terminals are variations of others. To do that you have to write a program to go into them and pull the name string out. There is a name string in there, right? What does egrep do about the nulls? The bottom line, for me, is: This is UNIX. There are all these great tools available for working with text files. There is no excuse for arbitrarily munging stuff in binary without a good reason. Performance, when you haven't explored anywhere near all the options, is not a good reason. -- Peter da Silva `-_-' Ferranti International Controls Corporation. "Have you hugged U your wolf today?" peter@ficc.uu.net