TERMINFO to TERMCAP conversion.

Phong Vo[drew] kpv at ulysses.att.com
Sat Apr 14 04:28:21 AEST 1990


In article <15074 at cbnewsc.ATT.COM>, levy at cbnewsc.ATT.COM (Daniel R. Levy) writes:
> In article <OHT2AIAxds13 at ficc.uu.net>, peter at ficc.uu.net (Peter da Silva) writes:
> > > The database parsing issue is the one thing I don't see how you could
> > > fix using compatible extensions to termcap.
> > 
> > Set up an index file, that you rehash whenever you change it. This is a
> > solved problem.
> 
> And if the sysadmin ever forgets to rehash after a termcap edit...
> curses programs all of a sudden start going BOOM...
> 
Yes, this can be a bit troublesome. The last time I looked, the largest
termcap file we have is about 2700 lines and ~130K. This can be read
fairly quickly. The main problem with the tgetstr, tgetnum crowd is that
they go thru an entry linearly for each capability. This means quadratic
time for parsing an entire entry. This is where all the time is spent
for the termcap accessing functions. Assuming that all the capability
names are known in advance, it's not too hard to automatically generate
these functions so that the parsing time for an entry is linear in its length.
This is the method used in my personal version of curses which can also support
both termcap and terminfo simultaneously. It is really no big deal
to write code that knows about both database formats. It certainly obviates
the need to argue the merits of either.



More information about the Comp.unix.questions mailing list