terminfo

[Peter da Silva]

In article <3194 at pegasus.UUCP>, hansen at 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 at ficc.uu.net