bet@ecsvax.UUCP (Bennett E. Todd III) (05/14/86)
In article <2774@pegasus.UUCP> hansen@pegasus.UUCP (60545457-Tony L. Hansen;LZ 3B-315;6243) writes: >... More to the point, when will Berkeley support terminfo? ... While I won't dispute the claim that terminfo is more expressive, I still find it to be a HUGE step backwards in design: there just isn't sufficient justification for making the active, working database a compiled binary file -- PARICULARLY when AT&T then doesn't include the sources to the terminfo descriptions. As shipped, the description for the DMD5620 is noticibly broken. To fix it, I'll have to completely rewrite the entire thing, since the readable (modifyable) version isn't available. Termcap isn't as expressive, perhaps, but I can write and modify termcap descriptions easily. Terminfo is a loser. Indeed, when I bring up full-screen applications (e.g. EMACSs) under System V, I use termcap. I have a public-domain rewrite of libtermcap, which a friend of mine wrote in response to AT&T's leaving it out of System V. Let us hope that Berkeley continues to support the better organized design, and doesn't attempt to corrupt BSD UNIXs too badly in the name of compatability. -Bennett -- Bennett Todd -- Duke Computation Center, Durham, NC 27706-7756; (919) 684-3695 UUCP: ...{decvax,seismo,philabs,ihnp4,akgua}!mcnc!ecsvax!duccpc!bet
keith@enmasse.UUCP (Keith Crews) (05/15/86)
In article <1553@ecsvax.UUCP> bet@ecsvax.UUCP (Bennett E. Todd III) writes: . . . >still find it to be a HUGE step backwards in design: there just isn't >sufficient justification for making the active, working database a >compiled binary file -- PARICULARLY when AT&T then doesn't include the >sources to the terminfo descriptions. As shipped, the description for >the DMD5620 is noticibly broken. To fix it, I'll have to completely >rewrite the entire thing, since the readable (modifyable) version isn't >available. The following was true for release 1 of system V - I do not know if it has since been improved. It turns out to not be hard (1-2 days) to write a program that takes the binary terminal description and turns it into ascii that can be editted and then recompiled using tic. There was a shell script that was printed in some Unix magazine a while back that did a similar thing. You will find that many (all?) of the terminfo descriptions distributed with system V are useless for using anything but vi. The automatic translator does an incomplete and often syntactically incorrect job. Even worse, tic does not flag many (any?) errors on input. So if you misspell a terminal capability, rather than being told that you have an error, it just quietly ignores that specification. After I wrote the above program it at least provided a method for determining what terminfo description you are really using and verifying that what you thought you specified actually got compiled into the database. (I'd post the program if I could but I can't.) Keith Crews
mac@tflop.UUCP (Mike Mc Namara) (05/16/86)
In article <1553@ecsvax.UUCP> bet@ecsvax.UUCP (Bennett E. Todd III) writes: >In article <2774@pegasus.UUCP> hansen@pegasus.UUCP (60545457-Tony L. Hansen;LZ 3B-315;6243) writes: >>... More to the point, when will Berkeley support terminfo? ... > >While I won't dispute the claim that terminfo is more expressive, I >still find it to be a HUGE step backwards in design: there just isn't >sufficient justification for making the active, working database a >compiled binary file -- PARICULARLY when AT&T then doesn't include the >sources to the terminfo descriptions. As shipped, the description for >the DMD5620 is noticibly broken. To fix it, I'll have to completely >rewrite the entire thing, since the readable (modifyable) version isn't >available. Termcap isn't as expressive, perhaps, but I can write and >modify termcap descriptions easily. Terminfo is a loser. Indeed, when I >bring up full-screen applications (e.g. EMACSs) under System V, I use >termcap. I have a public-domain rewrite of libtermcap, which a friend >of mine wrote in response to AT&T's leaving it out of System V. Let us >hope that Berkeley continues to support the better organized design, and >doesn't attempt to corrupt BSD UNIXs too badly in the name of >compatability. > >-Bennett >-- > >Bennett Todd -- Duke Computation Center, Durham, NC 27706-7756; (919) 684-3695 >UUCP: ...{decvax,seismo,philabs,ihnp4,akgua}!mcnc!ecsvax!duccpc!bet Ok, ready or not: Mark Horton, of ATT (just before he joined ATT), and Pavel Curtis, of Cornell, wrote a public domain package called terminfo, which came out, I believe, before AT&T's version. This system included ncurses, which was a much improved version of curses. It also included vi(1) setup to use said ncurses. It also included dump(1), an unfortuate overloading of the term, which would uncompile terminfo library entries. As I don't have access to SYS5, I can't see if this works on those said libraries. I also have a program which reads in termcaps and writes out terminfo input files. Any and all of this is in the public domain, and available from me via return request. I include the man page for dump: DUMP(1) UNIX Programmer's Manual DUMP(1) NAME dump - Print the contents of a compiled terminfo file in human-readable form SYNOPSIS /etc/term/dump file ... DESCRIPTION Dump reads the given files and decodes their contents to ---- derive a reasonable representation of the terminfo entry which produced the file originally. It should be noted, in case of emergency, that the output of dump is perfectly ---- usable as the input to compile(1). ------- SEE ALSO compile(1), term(5), terminfo(5) AUTHOR Pavel Curtis, Cornell University (decvax!cornell!pavel or Pavel.Cornell@Udel-Relay) BUGS You tell me. -- ---------------------------------+-------------------------------------------- | Michael Mc Namara | Let the words by yours, I'm done with mine. | UUCP: dual!vecpyr!tflop!mac | May your life proceed by its own design. | ARPA: tflop!mac@ames.arpa | ---------------------------------+--------------------------------------------
parmelee@bullwinkle.cs.cornell.edu (Larry Parmelee) (05/16/86)
In article <1553@ecsvax.UUCP> bet@ecsvax.UUCP (Bennett E. Todd III) writes: > -- PARICULARLY when AT&T then doesn't include the >sources to the terminfo descriptions. As shipped, the description for >the DMD5620 is noticibly broken. Yeah, I just got done fixing that myself. Inspires all sorts of confidence, etc... I've posted my fixed terminfo source for the DMD to net.sources, Message-Id: <2225@bullwinkle.cs.cornell.edu> and a cute little shell script for un-compiling terminfo entries. Help yourself. -Larry Parmelee parmelee@systems.cs.cornell.edu
mark@cbosgd.UUCP (Mark Horton) (05/18/86)
In article <2774@pegasus.UUCP> hansen@pegasus.UUCP (Tony L. Hansen) writes: >... More to the point, when will Berkeley support terminfo? ... The real question here is, when will AT&T let Berkeley use terminfo and the rest of System V. There are apparently some amazing legal discussions going on. Berkeley has been interested in terminfo since 1982, but they just haven't been able to include it without either requiring a System V license or getting sued. There turned out to be a lot of problems with requiring their users to get a System V license. In article <1553@ecsvax.UUCP> bet@ecsvax.UUCP (Bennett E. Todd III) writes: >While I won't dispute the claim that terminfo is more expressive, I >still find it to be a HUGE step backwards in design: Everyone is entitled to their opinion, of course, but I think Mr. Todd is primarily annoyed because he has managed to get a binary-only system. I can understand his frustration at trying to use a UNIX without sources, and not just with terminfo. If he had source, he could look in /usr/src/lib/libcurses/terminfo for the sources. As to the problems with the 5620 description, it turns out that the version of curses/terminfo in System V Release 2 was frozen in April 1983, and I think the 5620 was just coming out at the time. There may be differences between the version of 5620 ROMs you have and the terminfo that happened to come with your system. It's easy enough to fix, with or without source, in release 3 using infocmp (an amazing program, which slices, dices, diffs binaries, uncompiles, and translates between termcap and terminfo.) To set the record straight, the public domain terminfo curses that Pavel Curtis wrote was written entirely by him. I was not involved in it at Berkeley or at Bell Labs. I did, however, write the System V release 2 version. (The release 3 version had input from me, but several others did most of the work, making major enhancements.) By the way, the person who rewrote libtermcap to have one for the public domain wasted their effort - the original implementation, from Berkeley, has always been public domain. The complaint that tic doesn't find syntax errors in terminfo descriptions is amusing, especially when it appears to be used as the basis for an argument that termcap is better than terminfo. Either syntax would permit an error checking implementation, although I don't know if you'd want the syntax checked every time vi started up :-) The SVr2 tic was just a modified version of the termcap file reading code, which also doesn't notice syntax errors. The SVr3 tic is completely redone (it's based on Pavel Curtis's tic) and is fairly fussy about syntax errors. It's also more complete, uses the existing binary database, and is much faster. I think when comparing termcap to terminfo, the real differences are: (1) terminfo has more capabilities, although most of these can be ported back to termcap without too much trouble. (2) terminfo can do some things termcap can't, e.g. tparm is fundamentally more powerful than tgoto. (3) terminfo does more at compile time, so it's better for a production environment. (4) termcap is more like an interpreter, so it's a bit more convenient for a development environment. (5) it's easier to dynamically construct a termcap description and put it in the environment than a terminfo. This happens to matter for one telnet-like program at MIT that emulates the subset of a standard terminal whose functiona match the hardware you have. It would also matter for a window manager (where the window size can vary) if it weren't for features designed to let you override the lines/columns capabilities. Mark Horton
mark@cbosgd.UUCP (Mark Horton) (05/18/86)
In order to compare the difference between termcap and terminfo with something we are all more familiar with, I'm paraphrasing Mr. Todd's posting, substuting a different example. Let's compare C (a compiled language) with shell (an interpreted language) and observe that binary versions of UNIX still have readable (and editable) shell scripts. >While I won't dispute the claim that C is more expressive, I >still find it to be a HUGE step backwards in design: there just isn't >sufficient justification for making the active, working program a >compiled binary file -- PARICULARLY when AT&T then doesn't include the >sources to the C programs. As shipped, the description for >the xyztool is noticibly broken. To fix it, I'll have to completely >rewrite the entire thing, since the readable (modifyable) version isn't >available. The shell isn't as expressive, perhaps, but I can write and >modify shell descriptions easily. C is a loser. Let us >hope that Berkeley continues to support the better organized design, and >doesn't attempt to corrupt BSD UNIXs too badly in the name of >compatability.
bet@ecsvax.UUCP (Bennett E. Todd III) (05/21/86)
In article <2146@cbosgd.UUCP> mark@cbosgd.UUCP writes: >In order to compare the difference between termcap and terminfo with >something we are all more familiar with, I'm paraphrasing Mr. Todd's >posting, substuting a different example. Let's compare C (a compiled >language) with shell (an interpreted language) and observe that binary >versions of UNIX still have readable (and editable) shell scripts. (followed by my complaints about terminfo, with the described substitutions) Not bad! Made me think for a bit. However, as you say, "binary versions of UNIX still have [...] shell scripts." Quite true. There are good reasons why shell scripts are better suited to some applications than C programs, and vice versa. Shell scripts are readily customizable; they take less space; shell scripts are the appropriate language when all that is desired is some straightforward combination of existing tools. Compiled C programs are better suited to some applications. They generally run much faster; they have ready access to all the system calls; and C is a better language for expressing complex data structures (and, to a lesser degree, algorithms). However, the analogy isn't exact. Specifically, there is a tradeoff that must be addressed whenever one is deciding on a database organization: will you use a compiled (packed) binary representation, saving time when reading the database, or will you use a straight (ideally reasonably free-form) textual format, preserving the usefulness of the large assortment of UNIX tools which assist in manipulating files of textual data? The case of terminal descriptions seems like a middle ground -- people have different views. Termcap has the benefits of a readble database format. Terminfo is faster in the worst case. How often do you access every term[(cap)|info)] description? Not in the lifetime of most UNIX systems, I'd imagine. A termcap database sorted approximately in decreasing order of frequency of use should be at least as fast as the repeated directory lookups required to descend the terminfo tree -- and termcap format is *trivial* to parse. Quite a few people have suggested I look up the infocmp utility and go away. Probably, if I had one, I'd never have been so preturbed about the intrinsic loss of flexibility that comes with a binary representation to have posted a gripe to the net. However, AT&T has shipped far too many UNIX's (including all the System V's I've gotten a crack at) *without* infocmp for that to be terribly persuasive. If speed is what you want, sort /etc/termcap in decreasing order of frequency of use. If that's not good enough for you, cram your termcap definition in the environment variable TERMCAP and leave terminfo behind entirely, when it comes to speed. If you are out to obstruct people trying to do new and interesting things, then by all means take every step available to encode any datafiles in the most intractable fashion available -- and don't try to sell me your product. As I said, terminfo is more expressive than termcap; that, however, is unrelated to the compilation of the terminfo descriptions, and isn't anything that couldn't be added to termcap. Hell, I am not wedded to /etc/termcap format inextricably; if we had /etc/terminfo with the source forms of terminfo descriptions, and if that's what the terminfo library worked from, then I'd have no serious complaints (except for the gratuitous incompatability of formats, which might be justifiable given how much nicer terminfo's is). But encoding the source description in a binary format buys you nothing that cannot be gotten in less obstructive ways. -Bennett -- Bennett Todd -- Duke Computation Center, Durham, NC 27706-7756; (919) 684-3695 UUCP: ...{decvax,seismo,philabs,ihnp4,akgua}!mcnc!ecsvax!duccpc!bet
bet@ecsvax.UUCP (Bennett E. Todd III) (05/21/86)
P.S. I made passing reference to the applicability of standard UNIX text manipulation tools to readable textual databases, without giving a specific example. I type % grep <terminal-type> /etc/termcap to find out what to set TERM to pretty often. Just for instance. -Bennett -- Bennett Todd -- Duke Computation Center, Durham, NC 27706-7756; (919) 684-3695 UUCP: ...{decvax,seismo,philabs,ihnp4,akgua}!mcnc!ecsvax!duccpc!bet
mellon@mit-prep.ARPA (Ted Lemonmellon/.name) (05/21/86)
> Everyone is entitled to their opinion, of course, but I think Mr. Todd is > primarily annoyed because he has managed to get a binary-only system. I > can understand his frustration at trying to use a UNIX without sources, > and not just with terminfo. If he had source, he could look in > /usr/src/lib/libcurses/terminfo for the sources. Considering the *huge* cost of a source license for UNIX, if you don't happen to be an educational institution, this statement is ridiculous. In order for UNIX to be useful, it either has to come with source code for a reasonable price (my preference), or it has to *work right*! _MelloN_ P.S. (Pure Sacrilege) I don't think UNIX is particularly useful. -- Ted Lemon Project GNU of the Free Software Foundation UUCP: {}!mit-eddie!mit-prep!mellon INTERNET: mellon@prep.ai.mit.edu ORGANIZATION: Project GNU, Free Software Foundation, 1000 Mass. Ave., Cambridge, MA 02138, USA +1 (617) 876-3296 HOME: 18 Kennedy Drive, North Chelmsford, Massachusetts
mark@cbosgd.UUCP (Mark Horton) (05/27/86)
In article <1596@ecsvax.UUCP> bet@ecsvax.UUCP (Bennett E. Todd III) writes: >The case of terminal descriptions seems like a middle ground -- people >have different views. Termcap has the benefits of a readble database >format. Terminfo is faster in the worst case. How often do you access >every term[(cap)|info)] description? Not in the lifetime of most UNIX >systems, I'd imagine. It's quite true that the analogy isn't exact. In particular, there are gobs of applications where shell is more appropriate than C. From my experience, I have run across only a single application where termcap is more appropriate than terminfo. By the way, I stated earlier that termcap was more convenient for a development environment. What I meant was an environment where termcap or terminfo descriptions are being developed. If you're developing something else, then you have a production environment as far as termcap/terminfo is concerned. >A termcap database sorted approximately in >decreasing order of frequency of use should be at least as fast as the >repeated directory lookups required to descend the terminfo tree -- and >termcap format is *trivial* to parse. > >If speed is what you want, sort /etc/termcap in decreasing order of >frequency of use. If that's not good enough for you, cram your termcap >definition in the environment variable TERMCAP and leave terminfo behind >entirely, when it comes to speed. I used to think this too. I was at Berkeley when we decided how to sort termcap files and put them into the environment. It helped a lot. But it turns out that even if you put a termcap in your environment, it's still too slow. The termcap algorithm for reading the entry into a set of capabilities is QUADRATIC on the size of the entry. This is the nature of the beast - because of tc=, you have to start from the left for each capability search. As termcap descriptions got longer, starting up vi grew slower and slower. It was taking 1/4 second of CPU time on a VAX 750 to parse the termcap entry, even when it came out of the environment. This was when I decided to move to a compiled format. Things get much simpler for the typical user - no need for the whole entry in the environment anymore, or the hair of tset -s in the .profile/.login. The ps command was breaking from the huge environment entries that took the arguments off the top page of memory. Forks were expensive. And it took too long to start up vi. All these problems went away when terminfo was compiled. Termcap format is trivial to parse, IF you are willing to put up with some of the disadvantages of interpreters, such as no error messages, slow speed, and the size of the parser. If you wanted to get good error messages, termcap would be as hard to parse as terminfo. (For those who are not impressed with tic's error messages, the SVr2 tic, which was frozen for SVr2 in April 1983 along with the rest of curses, is essentially the termcap parser. The SVr3 tic is completely redone, by Pavel Curtis, and it's as fussy as pcc.) And I'm sorry you can't get SVr3 yet, and that in the meantime you're all using 3 year old code. We don't control the release dates, and curses hasn't been what's holding up SVr3. You might look to see if you got the "ti4" program with SVr2, which dumps out a terminfo binary, although not in tic-readable form. I think it was in the source dir but not normally installed. It's the only tool we had for printing out the binaries back in 1983. Mark
bzs@bu-cs.UUCP (Barry Shein) (05/29/86)
Now you have me really confused. Ok, I believe that compiled terminfo entries are much faster than termcap entries (of course, this goes against the grain of current technological trends, on a 750 with 20 users, sure, bring it on!, on a SUN/3 workstation? who cares. ok, it was written when a 750 was still "a thing".) But there's more going on. Why couldn't I create a compiled format for termcap? Sounds like around, oh, a full day's work or so, use DBM for the basic lookup and read in a pre-parsed, sorted/hashed table. I could then just rebuild that whenever my termcap file changed. Could even compile things like cursor motion into a faster format (or am I missing a difficulty here, surely I could gain most of the speed back.) Obviously there has to be something else here than raw speed. I've never looked at terminfo much tho I have it on one of the machines here. Why is this discussion centering around speed so much? Is that the only issue? (particularly, speed of start up, I know CCA Emacs claimed that with terminfo screen updates were around the same as custom C screen handlers, parsing is long over by then.) -Barry Shein, Boston University
mark@cbosgd.UUCP (Mark Horton) (05/31/86)
Why not compile termcap? Well, if you did compile termcap, you'd probably come up with something essentially the same as terminfo. The padding and parameters would be different, but otherwise it would be very close. (Time to interpret tparm strings is not really an issue.) You ask why a 750 should matter now. What about all those folks out there with IBM PC's, 1/4 of a 750? What about all the Sun 2's, which are 1 750? What about the 3B2/300, and the varous 68K boxes and 68010 boxes, and NSC boxes? They all tend to be in the 750 performance range. I can assure you that a difference of half a second or so of real time to start up vi makes a big difference in perceived response. Also, that was 1/4 second of CPU time on a 750 with a 1982 termcap description. The descriptions are getting longer, as more function keys and other capabilities are added. "Quadratic" gets worse real quick as things get bigger. (Oh, by the way, cbosgd is still a 750, and with no way from DEC to upgrade it, it will likely always be a 750.) Yes, there are some differences and incompatibilities. Termcap was running out of room for expansion. With only two chars for capability names, the names being chosen were no longer mnemonic. The padding conventions (leading digits) were unable to describe some things that needed description, such as visible bell, resulting in various kludges that didn't work well (inserting a fixed number of pad characters, guessing at the baud rate.) But the real killer was that tgoto had room for only two parameters, and the parameters were backwards. There was no way to handle complex terminals that needed tests and arithmetic. There was no way to handle features like combined attributes, or windows, because these capabilities needed more than two parameters. Finally, there was the expectation on my part that I would be able to take the resulting terminfo, give it back to Berkeley, and it would naturally take the place of termcap. I expected termcap to be dead within a year or so. This was in 1982, when AT&T wasn't so gung-ho about proprietary software, or so intent on pushing System V as a standard. It has since turned out that Berkeley can't include it without requiring a System V license, which they were unable to do for unrelated reasons. And there are enough places out there running derivitives of ancient versions of UNIX (including Xenix, for example) that just get termcap by default. Since I thought termcap would be dead quickly, I didn't worry as much about compatibility as I should have. This is unfortunate, and with 20/20 hindsight, we all realize what we could have done differently. As it stands, terminfo does have the distinction of being designed strictly on "best technical" grounds, with no compromises for compatibility. Once the licensing issues are taken care of, and once SVr3 is widely available (with the infocmp utility) these pains will be greatly eased. If I had my way, I'd just post it to mod.sources, but of course, I'd quickly be looking up the wrong end of a lawsuit, not to mention an unemployment line. Mark
ignatz@aicchi.UUCP (Ihnat) (06/11/86)
Actually, Mark, some time ago a public domain version of terminfo was posted--in fact, I think it was to mod.sources, although I'd have to go unpack my archived copy to make sure. I got it running on an Altos running Xenix 3.0b (and later, 3.1a), so I'm sure it'll work on just about anything. (disgruntled :-)) The only real complaint I had was that the entry maintenance isn't as nice as the real 'tic', but that's a trivial rewrite; and, certainly, there are new, different, and surely better bugs that my simple validation testing didn't find. But it's certainly a good, working base that (author willing) the Berkley types could incorporate. I'm finding that it's utterly invaluable, as so many programs are being written now for *only* terminfo. -- Dave Ihnat Analysts International Corporation (312) 882-4673 ihnp4!aicchi!ignatz || ihnp4!homebru!ignatz