ricker@bunker.UUCP (James A. Ricker) (04/29/86)
In curses.h there is a comment to the effect that 64 function keys are supported However, the structures in term.h only have members for 0-10 function keys. How are you handling this? Any ideas welcome. Thanks, Ricker
robt@molihp.UUCP (Robert L Thurlow) (05/03/86)
<> In article <1135@bunker.UUCP> ricker@bunker.UUCP (James A. Ricker) writes: >In curses.h there is a comment to the effect that 64 function keys are supported >However, the structures in term.h only have members for 0-10 function keys. >How are you handling this? Any ideas welcome. > When we upgraded to HP-UX 5.01, I saw this too, and I got excited. I must support terminals with SHIFT-able function keys, and my logic said to use terminfo f0-f15 for unshifted versions, f16-f31 for shifted versions, f32-f47 for keys with the control key, and f48-f63 for shift-control. Tek 4105's will even do all this, and all our decent terminals work with shift. The space IS EVEN RESERVED in the terminfo entry. The snag is that 'tic(1M)' will only stuff pointers for f0-f10 into the terminfo file, and 'tgetstr(3)' will only read f0-f9! This is irritating, since I can taste getting those keys legally. At present, I use the function key labels l0-l7 for actual strings returned by those shifted keys, which is not good, and I need my own routine to think about what keys have been pressed. I feel like I could write my own terminfo from scratch by now. Sigh. # UUCP : ...!ubc_vision!molihp!robt Robert Thurlow # # My thoughts are my own, and are void where prohibited by law. # # "There was something fishy aboout the butler. I think he was a # # Pisces, probably working for scale." -Nick Danger, 3rd Eye #
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
fnf@unisoft.UUCP (Fred Fish) (05/17/86)
In article <233@tflop.UUCP> mac@tflop.UUCP (Mike Mc Namara) writes: > 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 AARRRRGGGGGG!!!! One of the utilities in the "generic" 68000 Unix system V port done by Motorola is a program called... you guessed it.... dump! This one "dumps" Common Object Format Files (COFF) in human readable format... -Fred =========================================================================== Fred Fish UniSoft Systems Inc, 739 Allston Way, Berkeley, CA 94710 USA {ucbvax,lll-lcc}!unisoft!fnf (415) 644 1230 TWX 11 910 366-2145 ===========================================================================
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.
H_Eidnes%vax.runit.unit.uninett@nta-vax.arpa (H}vard Eidnes) (05/20/86)
>> 4) I didn't notice it in the description, has anyone standardized means >> of drawing boxes in both berkley and system V? (I don't mean drawing >> random lines, but replacing building boxes out of |, +, and - chars. In response to this, Tony L. Hansen writes: > One of the terminfo strings is named acs_chars (a.k.a terminfo "acsc" or > termcap "ac"). It has defined within it what the alternate line drawing > character set is for that terminal. With those characters and the > enter/exit_acs_mode strings, very nice boxes and other graphics may be > drawn. > [ goes on to describe how this is done ] I think the method to describe line-drawing capabilities is far too Vt100-specific. Not all terminals use "shift-in" and "shift-out" to switch between character sets. For instance, the terminal I currently use, has only a "single-shift" command (ESC N), valid for the next character only to select character sets. I once tried to define this terminal using an "extended" termcap, using this method for selection of character sets. First, I had to define the shift-in and shift-out sequences to be non-null (the termcap package refused to use semi-graphics otherwise), so I set these up to send padding characters only to the terminal. Next, I defined each of the entries for the line-drawing capabilities to include the single-shift sequence, but alas, the termcap package assumed that only a single character would be needed... So I had to revert to using +, - and ! (remember, I'm from Scandinavia, and "|" is "reserved for national extensions"...). What I would like, is to have a more general way to define semi-graphics, that allowed non-vt100-lookalikes to be defined also. As for terminfo vs. termcap, I think terminfo is superiour in generality (because of the "programmable" parameter setting). But then again, termcap is general enough to describe most terminals...
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!betmellon@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
rab@smu (06/02/86)
in my opinion, this is boiling down to the age-old war between the unixes. i personally find the improvements embodied in terminfo (both speed and syntax) pleasing from a system management perspective. termcap has become so incredibly cluttered that there are definitions with capabilities for which i am really not sure what they do -- and they are NOT documented in anything i have. the one true valor that terminfo has is its organization and clarity. in the realm of speed, there really does seem to be this need. with the advent of more and more smaller machines taking on more and more applications in the business world, the idea of terminfo is probably sound. hope i am not starting another chapter to this discussion. rick barrett convex!smu!rab
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
allbery@ncoast.UUCP (Brandon Allbery) (07/31/86)
Expires: Quoted from <2604@brl-smoke.ARPA> ["Termcap, terminfo, and curses."], by SLG6M%USU.BITNET@WISCVM.WISC.EDU... +--------------- | > Read TERM(4) and rewrite using terminfo. You won't be sorry; terminfo is much | > cleaner than termcap. | | You *can't* "rewrite using terminfo." Because terminfo is just a DATABASE. | The routines in question are called curses (which, by the way, also exist | on non-AT&T systems like BSD). +--------------- But (take my word for it) a program written to use termcap is a royal pain in the a** to convert to curses. ``Terminfo'' is the name of a database, yes, but it's also commonly used as the name for the low-level routines used to access the terminfo database. They are, however, accessed via -lcurses. Still, the low-level routines never heard of windows, etc.; and while curses can't use a terminal's status line, the low-level terminfo routines are able to use the "tsl", "fsl", "dsl", and "eslok" attributes. Amongst others. ++Brandon -- ---------------- /--/ Brandon S. Allbery UUCP: decvax!cwruecmp! / / /|\/ Tridelta Industries, Inc. ncoast!tdi2!brandon ---- -------- /-++ 7350 Corporate Blvd. PHONE: +1 216 974 9210 / / /---, ---- Mentor, Ohio 44060 SYSOP: UNaXcess/ncoast / / / / / / -- HOME -- (216) 781-6201 24 hrs. / / / / / / 6615 Center St. Apt. A1-105 ARPA: ncoast!allbery% ---- -----~ ---- Mentor, Ohio 44060-4101 case.CSNET@csnet-relay