Path: utzoo!utgpu!watserv1!watmath!att!ulysses!kpv From: kpv@ulysses.att.com (Phong Vo[drew]) Newsgroups: comp.unix.questions Subject: Re: TERMINFO to TERMCAP conversion. Summary: with a little bit of work, you can have your cake and eat it too Message-ID: <12789@ulysses.att.com> Date: 13 Apr 90 18:28:21 GMT References: <9237@cbnewsh.ATT.COM> <461@svcs1.UUCP> <15074@cbnewsc.ATT.COM> Organization: AT&T Bell Laboratories, Murray Hill Lines: 23 In article <15074@cbnewsc.ATT.COM>, levy@cbnewsc.ATT.COM (Daniel R. Levy) writes: > In article , peter@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.