rgsmeb@abcom.ATT.COM (Michel Behna) (04/07/88)
Help me!!!
Does anyone out there have a terminfo for an ibm pc running monochrome graphics
and is willing to share it? Preferably it will support all the function keys
and also the numeric/ cursor keypad. This is for personal use on an ibm
pc compatible with the original kyboard i.e. not the enhanced 101 kybd.
I would appreciate it if you would either post a followup or email it to me.
I read the first two groups but not the last two.
Thank you in advance!
Michel Behna Qui a eu l'idee folle
"Unix is unique!" D'inventer un jour l'ecole
rgsmeb@abcom.att.com C'est se sacre Charlemagne
{ncsc5,codas}!abcom!rgsmeb
--
Michel Behna Qui a eu l'idee folle
"Unix is unique!" D'inventer un jour l'ecole
rgsmeb@abcom.att.com C'est se sacre Charlemagne
{ncsc5,codas}!abcom!rgsmebdca@kesmai.COM (David C. Albrecht) (06/10/88)
I've been playing around with wm in conjunction with the SYS5 pty driver to get it to work on the UNIX PC. I have some real basic functionality but I just realised, however, that I don't think the mechanism of TERMCAP where you can define an environment variable which contains the termcap entry for your terminal exists with terminfo. Am I wrong? Ideas? Alternatives? Thanx in advance. David Albrecht
clp@altos86.UUCP (Chuck L. Peterson) (08/25/88)
Why does terminfo exist?
It makes much more sense to edit a /etc/termcap to install
new or different terminal capabilities.
For what purpose was there created a terminfo.src method
in which one must edit an ascii file containing the capability
in question followed by running "tic" on it? And why can't
terminfo.src have the same syntax and capability strings
as /etc/termcap? Having each terminal description in a
different /usr/lib/terminfo/?/file has 2 advantages:
1) you can use the filesystem to do hashed
lookup of the requested terminal description
2) the file can contain some sort of "struct terminfo"
which can be read quicker than parsing some ascii file
The right way to do this sort of thing would be to stick with
a system based on termcap, but use -ldbm to do hashed lookups
using a /etc/termcap.{dir,pag} dbm setup. Having the looked-up
data being a ascii string is what I would prefer, but this could
be a "struct terminfo" if you don't want to parse and have
room for bunches of these structs in your filesystem.
You would still have to run a tic-like program each time you
changed /etc/termcap; but you would get rid of this silly directory
hashing as well as the long search time associated with /etc/termcap.
(A vax750 running 4.3bsd takes a long time to determine you
typed in a bad term type when /etc/passwd is 250k.)
Chuck L. Peterson
...!sun!altos86!clpchris@mimsy.UUCP (Chris Torek) (08/25/88)
In article <508@altos86.UUCP> clp@altos86.UUCP (Chuck L. Peterson) writes: >Why does terminfo exist? Because the inventor (or at least prime mover: I think Bill Joy had a hand in the invention) of termcap noticed, after several years, that termcap was, as a terminal description language, atrocious. >It makes much more sense to edit a /etc/termcap to install >new or different terminal capabilities. I disagree, even though all I have is termcap. >For what purpose was there created a terminfo.src method >in which one must edit an ascii file containing the capability >in question followed by running "tic" on it? For the same reason that one compiles programs: term(cap|info) descriptions are used much more often than they are defined. (Personally, I believe that the overhead in interpreting a single description, even in the longer terminfo format, is small enough that interpreting it every time is no loss, and it would get rid of one serious botch in terminfo: you cannot easily add new capabilities.) >And why can't terminfo.src have the same syntax and capability strings >as /etc/termcap? Because (he says, entering Ron Natalie mode) the termcap syntax sucks. >Having each terminal description in a different /usr/lib/terminfo/?/file >has 2 advantages: > 1) you can use the filesystem to do ... lookup > 2) the file can ... be read quicker than parsing some ascii file Right on both counts. >The right way to do this sort of thing would be to stick with >a system based on termcap, but use -ldbm to do hashed lookups >using a /etc/termcap.{dir,pag} dbm setup. Well, dbm sucks too. (Half :-) ) As databases go, its main advantage is that it is there. >Having the looked-up data being a ascii string is what I would prefer .... I agree. I hear someone asking: `what is wrong with termcap, anyway?' All right, quick, tell me how you convert a cursor position to a base 8 one's complement row number offset by ' ' followed by a base 8 one's complement column number offset by ' ' and occupying two characters if and only if the value produced is by the first character is >= 95 (in which case the first character is stopped at 95 and the second is summed into the first, after bit-flipping and converting back from octal)? In fact, if you are unlucky enough to have a weird terminal like the above (whose cm string I made up for illustration, taking the worst features of two terminals we *do* have and adding a third), the way you write a cm string is that you edit the termcap library, adding a new flag, then recompile the library and all of /usr/src. With terminfo, you write a long and complicated cm string full of `%' operators, but you do it without having to kludge the source. (And yes, the one's complement terminals exist: the NIH 7000 is a modified Delta Data terminal, and we have far too many of them, since the University got them for a `mere' $200 each when NIH finally threw them out. We had to add a `%m' cm capability to cope with the beasts. The only feature I made up was the base 8 stuff. GTOMNI, a terminal emulator [of sorts] for the GT40, requires that the column number be sent in one character if < 64, else in two.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) (08/25/88)
In article <508@altos86.UUCP>, clp@altos86.UUCP writes:
< Why does terminfo exist?
< 1) you can use the filesystem to do hashed
< lookup of the requested terminal description
<
< 2) the file can contain some sort of "struct terminfo"
< which can be read quicker than parsing some ascii file
3) terminfo handles input escape sequences, such as what the arrow
keys return and what the function keys return, keyboard remapping, and
other useful input features that termcap just don't have.
--
--------
Christopher J. Calabrese
AT&T Bell Laboratories
ulysses!cjcvandys@hpisoa1.HP.COM (Andrew Valencia) (08/25/88)
/ hpisoa1:comp.unix.wizards / clp@altos86.UUCP (Chuck L. Peterson) / 1:25 pm Aug 24, 1988 / >Why does terminfo exist? >It makes much more sense to edit a /etc/termcap to install >new or different terminal capabilities. Why strchr (index), strrchr (rindex), /usr/mail (/usr/spool/mail)? Why VTIME, VMIN (cbreak)? Why sxt's (ptys), why regions (vmunix)? Why System V (BSD)? God, I need a drink. Andy Valencia p.s. :->
gwyn@smoke.ARPA (Doug Gwyn ) (08/25/88)
In article <508@altos86.UUCP> clp@altos86.UUCP (Chuck L. Peterson) writes: >Why does terminfo exist? Because termcap was too limited.
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (08/26/88)
In article <10544@ulysses.homer.nj.att.com> cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) writes: >3) terminfo handles input escape sequences, such as what the arrow >keys return and what the function keys return, keyboard remapping, and >other useful input features that termcap just don't have. But termcap *will* have that if you put it in... A significant advantage of termcap over terminfo is that it is "free form" ... you can add capabilities without having to redefine (and recompile) your database. I'm just playing Devil's Advocate, of course; I think terminfo is superior overall. -- -=] Ford [=- . . (In Real Life: Mike Ditto) . : , ford@kenobi.cts.com This space under construction, ...!ucsd!elgar!ford pardon our dust. ditto@cbmvax.commodore.com
barmar@think.COM (Barry Margolin) (08/26/88)
In article <10544@ulysses.homer.nj.att.com> cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) writes: >3) terminfo handles input escape sequences, such as what the arrow >keys return and what the function keys return, keyboard remapping, and >other useful input features that termcap just don't have. Maybe AT&T Unix doesn't have them, but I just checked the manual page for termcap on our Sun and it has k0-k9, which specify the sequences transmitted by function keys 0 thru 9 (unfortunaely, some terminals have more than ten numbered functions keys), and other specifiers for what other special function keys transmit. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
plocher@uport.UUCP (John Plocher) (08/26/88)
In article <4577@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: >>3) terminfo handles input escape sequences, such as what the arrow > >But termcap *will* have that if you put it in... A significant advantage >of termcap over terminfo is that it is "free form" ... you can add >capabilities without having to redefine (and recompile) your database. Except that only *you* will have compiled them in - if you give your stuff to me it will be useless unless I *too* modify my curses source. (if I am lucky enough to have it :-) I am assuming you wish to have a curses call such as getch() that returns a "value" such as 65 (for 'A') or 129 ('a umlaut') or 329 ('<F1>'). You aren't (I hope) assuming that the program which needs to 'see' a <F1> keypress will actually parse its input WRT the entry in the terminfo database? terminfo is useful in that it does this work for you - in a portable way. termcap requires your program to 'know' too much of how the terminal database is structured. -John Plocher But *why* it has to be in binary format I wouldn't know :-(
ccea3@rivm.UUCP (Adri Verhoef) (08/26/88)
In article <26445@think.UUCP> barmar@kulla.think.com (Barry Margolin) writes: >Maybe AT&T Unix doesn't have them, but termcap on our Sun has k0-k9, which ^^^^^ --------- ^^^^^^^ >specify the sequences transmitted by function keys 0 thru 9 (unfortunately, >some terminals have more than ten numbered functions keys), and other >specifiers for other function keys. Surprise! terminfo(4) on our UNIQ System V.3.0 microVAX II has, according to the manpage, 64 sequences (which is more than ten) for ordinary function keys, and 85 specifiers for what other funckeys transmit. It adds up to 273 capnames for strings, 11 for numbers, and 26 for variable booleans, and to reassure y'all, all capabilities also have a termcap code.
david@uowcsa.cs.uow.oz (David E A Wilson) (08/27/88)
In article <13202@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > I hear someone asking: `what is wrong with termcap, anyway?' All > right, quick, tell me how you convert a cursor position to a base 8 > one's complement row number offset by ' ' followed by a base 8 one's > complement column number offset by ' ' and occupying two characters > if and only if the value produced is by the first character is >= 95 > (in which case the first character is stopped at 95 and the second > is summed into the first, after bit-flipping and converting back from > octal)? How about this then? We have a set of VT220 compatible terminals which have added funtions such as labels at the bottom of the screen. The way to program both these labels & the function keys is to send the following (for an output/display of HELLO) (first key & label): Key: ESC P 1 ; 1 | 1 7 / 4 8 4 5 4 C 4 C 4 F ESC \ Label: ESC P 0 ; 1 r 0 / 4 8 4 5 4 C 4 C 4 F ESC \ How can I encode this so that the application does not need to encode the string in hex? Here are the terminfo definitions I use that do require this. pfx=%p1%Pa%?%p1%{5}%>%t%?%p1%{10}%>%t%?%p1%{14}%>%t%?%p1%{16} %>%t%ga%{14}%+%e%ga%{13}%+%;%e%ga%{12}%+%;%e%ga%{11} %+%;\EP1;1|%d/%p2%s\E\\%;, pln=\EP0;1r%p1%{1}%-%d/%p2%s\E\\, The gastly pfx string is because DEC in its wisdom saw fit to allocate numbers to the holes in between the function key groups. Clues anyone? David E.A. Wilson ACSnet: david@uowcsa.oz Dept. of Computing Science UUCP: ...!munnari!uowcsa.oz!david Uni. of Wollongong ARPA: david%uowcsa.oz@uunet.UU.NET
ado@elsie.UUCP (Arthur David Olson) (08/28/88)
> I hear someone asking: `what is wrong with termcap, anyway?' All > right, quick, tell me how you convert a cursor position to a base 8 > one's complement row number offset by ' ' followed by a base 8 one's > complement column number offset by ' ' and occupying two characters > if and only if the value produced is by the first character is >= 95 > (in which case the first character is stopped at 95 and the second > is summed into the first, after bit-flipping and converting back from > octal)?. . .The only feature I made up was the base 8 stuff. For our NIH7000's the similar problem got solved this way: :cm=%r\E_\ %D%>\60\200%\>40\240%\>20\300%>\340\01%>\01\337%>\360\377%+\377\ %D%>\60\200%>\40\240%>\20\300%>\340\01%>\01\337%>\360\377%+\377:-) -- ado@ncifcrf.gov ADO is a trademark of Ampex.
vic@zen.co.uk (Victor Gavin) (08/29/88)
Terminfo Wish List: Support for backtab as a keypad character (maybe even support for tab as a keypad character, not just ^I). Support for terminals which allow on screen labels to descibe function keys (ie something like lab_f* but allowing a string parameter instead of a cursor) Modify pkey_* to allow length of string instead of using just assuming a terminating character (eg support for length of string on stack, %l) Support sequences to control block mode applications. Support colour as well as standard high-lighting modes. Ability to use line drawing character sets (eg a set of commands that will emit corners, vertical lines, horizontal lines etc.) Ability to define re-definable character sets.
dgy@sigmast.UUCP (Dave Yearke) (08/29/88)
In article <4577@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: > ... A significant advantage >of termcap over terminfo is that it is "free form" ... you can add >capabilities without having to redefine (and recompile) your database. This can be a disadvantage, too. It is most annoying when different applications invent their own termcap capabilities and they "collide" by using the same mnemonics. Terminfo forces you to use its mnemonics, but it is complete enough that it usually doesn't matter. >I'm just playing Devil's Advocate, of course; I think terminfo is >superior overall. I agree. -- Dave Yearke, Sigma Systems Technology, Inc. 5813 Main St, Williamsville, NY 14221 ...!sunybcs!sigmast!dgy
daveh@marob.MASA.COM (Dave Hammond) (08/30/88)
If individual machines (at least under Xenix) can elect to install
either termcap or terminfo or both, is there any reasonable way to
write a program which normally uses terminfo, but can fall back to
termcap if terminfo isn't installed ? It seems to me that including
the code for both libraries in one program would add quite a bit of
overhead.
Dave Hammond
UUCP: {uunet|...}!marob.masa.com!daveh
DOMAIN: daveh@masa.com
------------------------------------------------------------------------------fst@mcgp1.UUCP (Skip Tavakkolian) (08/31/88)
In article <8377@smoke.ARPA>, gwyn@smoke.ARPA (Doug Gwyn ) writes: > In article <508@altos86.UUCP> clp@altos86.UUCP (Chuck L. Peterson) writes: > >Why does terminfo exist? > > Because termcap was too limited. Please explain. I have built termcap entries for AT&T610 and UNIXPC console (display and keyboard personality) following the AT&T ``suggested'' codes given in UNIXPC and newer (SYS V.3) 3B2 manuals. For every terminfo code there is a corresponding and for-historical-reasons two letter termcap code for each capability, including keyboard. I like termcap because I can take it with me. I tried to use a terminfo entry that was ``tic''ed on a 3B2-600 SVR3 with the codes added since SVR2, to a 3B2-400 with SVR2.0.4 and some programs ungracefully barf. Sincerely -- Fariborz ``Skip'' Tavakkolian UUCP ...!uw-beaver!tikal!mcgp1!fst UNIX is a registered trademark of AT&T
gwyn@smoke.ARPA (Doug Gwyn ) (09/01/88)
In article <1553@mcgp1.UUCP> fst@mcgp1.UUCP (Skip Tavakkolian) writes: -In article <8377@smoke.ARPA>, gwyn@smoke.ARPA (Doug Gwyn ) writes: -> In article <508@altos86.UUCP> clp@altos86.UUCP (Chuck L. Peterson) writes: -> >Why does terminfo exist? -> Because termcap was too limited. -Please explain. To take just one example, the cursor positioning sequence is not sufficiently programmable to accommodate some 132-column terminals.
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (09/01/88)
In article <440@uport.UUCP> plocher@uport.UUCP (John Plocher) writes: >In article <4577@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: >>>3) terminfo handles input escape sequences, such as what the arrow >> >>But termcap *will* have that if you put it in... > >Except that only *you* will have compiled them in - if you give your stuff >to me it will be useless unless I *too* modify my curses source. (if I am lucky >enough to have it :-) Right, but now we're talking about curses, not terminal database format; This applies to terminfo as well as termcap, (but more so with terminfo, because that recompilation would involve rebuilding the database as well). Curses can be (and has been) modified to use these input-sequence capabilities, regardless of whether it's using termcap or terminfo to read these capabilities from the database. I think I wasn't clear in my comment, which was essentially: terminfo/ termcap BOTH provide a database which retrieves "capabilities" and a method for instantiating parameters into output strings. These capabilities can be used for input, output, or whatever, by a user program or a library such as curses. To add new capabilities is easier with termcap. Standardizing new capabilities is equally easy(/difficult) with either format. >I am assuming you wish to have a curses call such as getch() that returns >a "value" such as 65 (for 'A') or 129 ('a umlaut') or 329 ('<F1>'). You >aren't (I hope) assuming that the program which needs to 'see' a <F1> keypress >will actually parse its input WRT the entry in the terminfo database? The terminfo/termcap routines shouldn't care whether they're being called by getch() or directly by user code. They should just return the string (or number) read from the database. >terminfo is useful in that it does this work for you - in a portable way. >termcap requires your program to 'know' too much of how the terminal >database is structured. Terminfo doesn't do that work, curses does. Terminfo and termcap both require some higher level software to do this interpretation... same thing with output. Most people use curses and don't worry about it. -- -=] Ford [=- . . (In Real Life: Mike Ditto) . : , ford@kenobi.cts.com This space under construction, ...!ucsd!elgar!ford pardon our dust. ditto@cbmvax.commodore.com
donn@r2d2.ACA.MCC.COM (Donn Baumgartner) (09/02/88)
In article <8412@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <1553@mcgp1.UUCP> fst@mcgp1.UUCP (Skip Tavakkolian) writes: >-In article <8377@smoke.ARPA>, gwyn@smoke.ARPA (Doug Gwyn ) writes: >-> In article <508@altos86.UUCP> clp@altos86.UUCP (Chuck L. Peterson) writes: >-> >Why does terminfo exist? >-> Because termcap was too limited. >-Please explain. > : > : > : This is ridiculous... if termcap had been 'supported' (in any real sense of the word), I doubt if there would be a terminfo... and if terminfo isn't supported any better than termcap was/is, there will be yet another 'standard' (if you can believe that two can be standard... sigh). (confession follows:) Years ago I extended Ken Arnold's version of curses for the IBM RT project to add support for multiple character attributes, fonts, colors, international languages, and box drawing (using box characters) - as well as bug fixes, etc. (And remnants of this can still be seen in AIX). But needless to say, this added support required additions to termcap (keep in mind that this was all taking place at the same time as Mark Horton was writing terminfo and the new curses). So, after much studying, I added all the necessary codes to termcap (like I said, AIX still uses these...). But I knew this was not enough, so I submitted these to termcap@berkeley so that they might actually become part of 'the standard'. Fat chance! The persons responsible for handling termcap@berkeley were apparently seriously overworked, and as such, just not very interested... the response alone took something like 6 months to come back(!). My basic contention here is that there wasn't *really* a need for an entirely new version of a terminal capabilities database... just a little support and maintenance for the existing version. All the complaints I've ever heard about termcap (which are typically used as justification for the existence of terminfo) can (and should) be fixed in termcap. Want more support for 'whatever'? - fine, add (or fix existing!) codes to termcap. Termcap is too slow? - fine, add an index at the start of the file (termcap is, after all, a database, right?), and make the index look like a termcap entry so as not to break old software (and etc.). No matter what the complaint, if terminfo can fix it, it can and could be fixed in termcap (by someone sufficiently interested in such). Don't get me wrong, although I think terminfo was unnecessary, it's not that I have anything against it... afterall, it does provide termcap capatibility codes for everything (which I promptly snarf-up and add to my termcap and curses routines :-). And (gosh...) this is like so many other things in the unix world... someone says "this isn't good enough", and they throw out the baby with the bath water. (I kind of like Columbia's approach to 'kermit'... when it needs fixing, they do... and they release another version - not an entirely new and incompatible program.) I've seen some vendors (names left out to keep the flames down) actually support their software... but it takes some amount of 'guts'... because fixing your software means admitting it was buggy (or insufficient) in the beginning. A lot of the new public domain software has gone this way... maybe the rest will follow. [end of religious rampage] - Donn Baumgartner _ ( ) \___|___/ Fear no Evil! | | Just wanna Skate... / \ __/ \__ Skate (Free) or Die! oo oo
madd@bu-cs.BU.EDU (Jim Frost) (09/04/88)
In article <8412@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: |In article <1553@mcgp1.UUCP> fst@mcgp1.UUCP (Skip Tavakkolian) writes: |-In article <8377@smoke.ARPA>, gwyn@smoke.ARPA (Doug Gwyn ) writes: |-> In article <508@altos86.UUCP> clp@altos86.UUCP (Chuck L. Peterson) writes: |-> >Why does terminfo exist? |-> Because termcap was too limited. |-Please explain. My vote is against terminfo. I found several problems with the supplied terminfo entries for the AT&T terminals (4435 I think) attached to 3b2's running SysVr2, as well as on the DMD graphics terminals. I tried to fix the problems, but there was NO documentation on how to do it, and the terminfo information is not in a format such that it can be figured out in a reasonable amount of time. Using termcap, I had some problems with the AT&T-supplied TERMCAP entry but I editted the entry and all was well. Similar problems with X11's xterm program were remedied the same way. The documentation was easy to find, but was also unnecessary in both cases. Perhaps terminfo is functionally "better", but my experience has shown it to be much less "maintainable". A broken "better" doesn't do much good. jim frost adt!madd@bu-it.bu.edu
gwyn@smoke.ARPA (Doug Gwyn ) (09/04/88)
In article <24729@bu-cs.BU.EDU> madd@bu-it.bu.edu (Jim Frost) writes: >My vote is against terminfo. I found several problems with the >supplied terminfo entries ... >I tried to fix the problems, but there was NO documentation on how to >do it, and the terminfo information is not in a format such that it >can be figured out in a reasonable amount of time. Sure there is documentation. It's TERMINFO(4) in the manual, which closely approximates the Berkeley TERMCAP(5) manual entry. Terminfo terminal description source files are more readable and easier to handle than the /etc/termcap database. You just edit the file and run "tic" over it to install the updated description in the database. Now, if your vendor neglected to supply you with the terminal description text files, that is the real problem. They should be provided even with a binary distribution (although they don't need to be loaded onto the system disk).
woods@gpu.utcs.toronto.edu (Greg Woods) (09/04/88)
In article <24729@bu-cs.BU.EDU> madd@bu-it.bu.edu (Jim Frost) writes: > In article <8412@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: > |In article <1553@mcgp1.UUCP> fst@mcgp1.UUCP (Skip Tavakkolian) writes: > |-In article <8377@smoke.ARPA>, gwyn@smoke.ARPA (Doug Gwyn ) writes: > |-> In article <508@altos86.UUCP> clp@altos86.UUCP (Chuck L. Peterson) writes: > |-> >Why does terminfo exist? > |-> Because termcap was too limited. > |-Please explain. > > My vote is against terminfo. I found several problems with the > supplied terminfo entries for the AT&T terminals (4435 I think) > attached to 3b2's running SysVr2, as well as on the DMD graphics > terminals. > > I tried to fix the problems, but there was NO documentation on how to > do it, and the terminfo information is not in a format such that it > can be figured out in a reasonable amount of time. > > [for termcap...] The documentation was > easy to find, but was also unnecessary in both cases. > > Perhaps terminfo is functionally "better", but my experience has shown > it to be much less "maintainable". A broken "better" doesn't do much > good. I doubt you will ever find a perfect terminal database in any Unix release, be it termcap or terminfo. I certianly wouldn't go so far as to call either "broken". [ NOTE: the first SCO release of terminfo was certianly broken. The terminfo compiler generated files incompatible with the terminfo library, but it has since been fixed. ] Just because you knew how to edit and fix a termcap entry, but not a terminfo entry, doesn't make terminfo a bad thing. I have found the terminfo documentation quite satisfactory for maintaining the database. It is no more complex (in my opinion) than that for termcap. I'd guess that your difficulty with finding the appropriate terminfo documentation has to do with the fact that the AT&T documentation is organized _slightly_ differently from the BSD documentation. DISCLAIMER: I have not seen the documentation supplied with AT&T 3B2 System V Release 2. I have a copy of the BSD 4.3 documents, the System V Release 2.1 generic (AT&T/CBS/HRW) documents, and the System V Release 3.0 documents, and I have used (extensively) the SCO Xenix 2.2.1 documentation. The terminfo library documentation that was supplied with Release 2.1 was little more than useless, but that has certianly been remedied in Release 3.0. In fact, the Release 3.0 Programmer's Guide is one of the best curses tutorials I've seen. My only complaint about terminfo is that it is HUGE. The "bulls eye" example from the programmers guide generates over 128 Kb of binary on a 386, from the 10 or so lines of code. Including any input functionality seems to double the binary again. Terminfo on a 286 uses a tremendous amount of stack space. Maybe AT&T will get around to building a shared library for curses.... -- Greg Woods. UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada
grs@alobar.ATT.COM (Gregg Siegfried) (09/05/88)
In article <24729@bu-cs.BU.EDU> madd@bu-it.bu.edu (Jim Frost) writes: >My vote is against terminfo. I found several problems with the >supplied terminfo entries for the AT&T terminals (4435 I think) >attached to 3b2's running SysVr2, as well as on the DMD graphics >terminals. > >I tried to fix the problems, but there was NO documentation on how to >do it, and the terminfo information is not in a format such that it >can be figured out in a reasonable amount of time. I have identified and repaired numerous terminfo descriptions, as well as written a few from scratch. Terminfo is well documented in the TERMINFO(4) section of the FM. >Using termcap, I had some problems with the AT&T-supplied TERMCAP >entry but I editted the entry and all was well. Similar problems with >X11's xterm program were remedied the same way. The documentation was >easy to find, but was also unnecessary in both cases. I'll assume you don't have source for the terminfo entries. When I want to fix a terminfo entry on a machine without source, I make the fixes on a machine with source, and send the file to the other machine ;-) No, seriously, if you have the infocmp(1M) program, you can generate the terminfo source from the compiled entry. You can even generate termcap source from a compiled terminfo entry. Then, armed with the manual pages and the terminfo source for the terminal in question, you can modify whatever you want. >Perhaps terminfo is functionally "better", but my experience has shown >it to be much less "maintainable". A broken "better" doesn't do much >good. I don't see it as any less maintainable at all. The only extra steps in reworking a terminfo entry are the infocmp and tic steps. Otherwise, it's exactly the same as modifying a termcap. Additionally, due to the more expressive syntax available with terminfo, it very likely takes less time. >jim frost >adt!madd@bu-it.bu.edu -- Gregg Siegfried | Nothing I say should be construed as AT&T AT&T - Cincinnati | policy or opinion .. I just hack here. UUCP: grs@alobar.att.com | Don't Rock - Wobble ARPA: grs%alobar@att.arpa | 513-629-8314 (work) 513-561-0368 (antiwork)
lkw@csun.UUCP (Larry Wake) (09/05/88)
In article <8431@smoke.ARPA>, Pnews swears gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) wrote: >Sure there is documentation. It's TERMINFO(4) in the manual, which >closely approximates the Berkeley TERMCAP(5) manual entry. ...so closely that it even helpfully suggests using "tset"... Both the terminfo and curses documentation for System V could stand a thorough going-over to eliminate the lingering Berkeley-isms, or at least indicate them as such. Or even better, implement them... -- Larry Wake lkw@csun.edu CSUN Computer Center uucp: {hplabs,rdlvax}!csun!lkw Mail Drop CCAD sun!tsunami!valley!csun!lkw Northridge, CA 91330 BITnet: LKW@CALSTATE
les@chinet.UUCP (Leslie Mikesell) (09/05/88)
In article <212@alobar.ATT.COM> grs@alobar.att.com (Gregg Siegfried) writes: >In article <24729@bu-cs.BU.EDU> madd@bu-it.bu.edu (Jim Frost) writes: > >>My vote is against terminfo. I found several problems with the >>supplied terminfo entries for the AT&T terminals (4435 I think) >>attached to 3b2's running SysVr2, as well as on the DMD graphics ^^^^ >No, seriously, if you have the infocmp(1M) program, you can generate the >terminfo source from the compiled entry. You can even generate termcap >source from a compiled terminfo entry. SysVr2 (at least on 3B2s) did not come with infocmp. Therefore there was no way to make a simple fix without re-creating the whole entry. As I recall, the termcap entries were not necessarily right either, nor identical to the terminfo entries. >I don't see it as any less maintainable at all. The only extra steps in >reworking a terminfo entry are the infocmp and tic steps. Otherwise, >it's exactly the same as modifying a termcap. Additionally, due to the >more expressive syntax available with terminfo, it very likely takes >less time. Unless you like to do things a step at a time and test them as you go. With termcap you could just throw the string into the environment and run a program. With terminfo you repeat the compile step for every change. I see the inability to use the environment as a real botch in terminfo. It means that you dedicate a disk block and inode to every terminal type that might ever be used on a system (including pseudo-terminals provided in windows by things like emacs). Also, if it is so flexible, why has it been necessary to change it with each release of unix since its invention? Les Mikesell
shocking@physiol.su.oz (Stephen Hocking) (09/06/88)
In article <8431@smoke.ARPA>, gwyn@smoke.ARPA (Doug Gwyn ) writes: > Now, if your vendor neglected to supply you with the terminal > description text files, that is the real problem. They should be > provided even with a binary distribution (although they don't need > to be loaded onto the system disk). Quite a few vendors now supply a program called "untic" instead of the text files. "untic ansi" spurts out the dis-assembled version on stdout. This is in a form which can be compiled by tic. What a lot of people haven't mentioned is that the system V curses actually knows about standout glitches and leaves a space as appropriate on the screen. Programming from the terminfo side of things is a bit easier, as one doesnt have to preallocate all those 1k buffers & go through painful tgetstrs, tgetnums etc etc. The thing is all pre-defined. Stephen ----
robert@pvab.UUCP (Robert Claeson) (09/07/88)
In article <1988Sep4.132939.26223@gpu.utcs.toronto.edu>, woods@gpu.utcs.toronto.edu (Greg Woods) writes: > Just because you knew how to edit and fix a termcap entry, but not a > terminfo entry, doesn't make terminfo a bad thing. One of the problems with terminfo is that one seldom gets the source file for the terminfo descriptions (ie, the input file for 'tic'). Oh yes, there is the infocmp command in SVR3.x, but it won't give me the comments in the original source. Disclaimer: I like terminfo. -- Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden Tel: +46 758-202 50 Fax: +46 758-197 20 Email: robert@pvab.se (soon rclaeson@erbe.se)
hansen@pegasus.UUCP (Tony L. Hansen) (09/09/88)
It's been interesting watching the recent discussions about terminfo and
curses, asking about the why's and wherefores, etc. As one of the people who
has been involved in the evolution of terminfo and curses, I thought I'd
add a little bit of real information to the net bandwidth.
1) why was terminfo created?
I believe that the main reason terminfo was written to begin with was that
the expressibility of arithmetic within a character attribute was severely
limited. Using the termcap arithmetic operators, one just cannot express all
of the different types of calculations necessary to handle the numerous
types of terminals present and appearing out there. Termcap is certainly
capable of handling numerous terminals, but there are just as many which it
cannot handle.
Once the decision was made to change the arithmetic capabilities of the
database to something which was more reasonable and usable with any
terminal, it was decided that it would be best to break away from the old
format entirely, allowing further improvements.
The longer names permit more capabilities to be supported easily. Although
there do exist equivalent termcap names for each and every terminfo name
there is, quick, what does the termcap "Fr" or "%1" capabilities represent?
The terminfo names of "kf63" and "khlp" representing the function-key #63
and the Help function key are certainly more usable.
The free-form input format and longer names, however, make it considerably
harder (and slower) to interpret the input file. Consequently, the compiled,
binary format and structure representation of the entire set of capabilities
permits very fast access to all of the capabilities. Termcap uses an n^2
algorithm to access capabilities.
2) How do I manipulate the database to change an entry?
All systems should have the uncompiled source to the terminfo database as
well as the compiled format. If yours doesn't, then complain to the vendor.
If you still cannot get the source, then you will have to make use of the
other tools available.
Unfortunately, System V release 2 didn't come with any way of looking at the
binary files. It's for that reason that I wrote the infocmp program which
subsequently was
o made available in source format for all via the AT&T Toolchest
at a very low cost
o added to System V release 3.0
There have also been similar programs posted to the net; untic is one.
In a similar vein, I wrote captoinfo to convert termcap entries into
terminfo source format. It also became available within the Toolchest and in
System V release 3.0. PD versions of this program have also appeared on the
net.
3) Why has terminfo changed over the past few years
All evolution to terminfo has been of two flavors:
o add new capabilities to more fully support different terminals
o add new arithmetic operations
This was all done in an upwardly compatible manner.
One should also be able to take a terminfo binary compiled on one release of
the system to another release of the same system. One should also be able to
take the binary from one system of one type and put it onto another system
of a different type, but there may be difficulties going from an 8-bit byte
machine to a 9-bit byte machine. If necessary, the binary file will be
scanned a byte at a time to collect the 16-bit integer values, as the format
is supposed to be completely portable no matter what the byte order of the
machine in use. There may have been some minor bugs in the SysVr2 version
preventing full support of this on some machines, but the intent was there
and works completely in SysVr3.
4) I want to access the alternate character set of the terminal
The terminfo capability "acsc" (alternate character set characters) defines
a complete map of the alt. character set. It was added in System V release
3.0. Curses has always supported A_ALTCHARSET as a bit map similar to
A_BOLD. Additional curses level support (added in SysVr3.0) for these
characters comes in the form of variables named ACS_* (like ACS_ULCORNER and
ACS_RTEE). Yes, these characters are automatically used by the box()
function.
5) I want to define my own capabilites
The user defined terminfo capabilities user0 to user9 were added in SysVr3.1.
You're free to do with these as you will.
6) I want to redefine things on the fly
For redefining the number of lines and columns, the most straight-forward
method is to use $LINES and $COLUMNS to override the values kept within the
database. The terminfo level routines look for these values. The
terminfo level routines may also look at a couple of ioctl values to
determine the size of the window, but these are less reliable when going
beyond the local machine's boundaries.
Redefining other capabilities is somewhat more complicated, but not
impossible. Those with a SysVr3.1 source licence should look at chgtinfo in
the curses directory. I don't know if or when chgtinfo will make it into the
mainline system. One would use it like this:
TERMINFO=`chgtinfo xhp, smso=\E[3m, smul@,`
export TERMINFO
This would create a temporary version of the current terminfo entry under
/usr/tmp using the given modifications.
7) How do I deal with supporting both termcap and terminfo versions of a
terminal?
I recommend that you maintain only the terminfo version, since it can
describe so much more about the terminal. Then use "infocmp -C" when
necessary to create the termcap version of the entry.
5) What has changed in curses?
Yes, the curses library has evolved somewhat since Mark Horton's original
rewrite, which appeared in System V release 2.
With System V release 3.0,
o considerable tuning to make it faster
o additional terminfo capabilities and arithmetic operations
o support for an alternate character set
o support for soft labels
o additional minor functions
o rewrite of the curses and terminfo manual pages
o rewrite of the chapter on curses and terminfo
in the Programmer's Guide
o tput enhanced
"tput init" provides the initialization capabilities of tset
tput can provide parameters to capabilities which require them
o infocmp added
o captoinfo added
With System V release 3.1,
o A rewrite of the insides of curses by K. Phong Vo.
The result is considerably smaller, yet faster, than all earlier
versions.
o many new functions
o internationalization: full support for 16-bit character sets and
removal of the 8-bit dependencies. This was done in both a binary
and source level compatible manner.
o additional terminfo capabilities
With System V release 3.2
o full support for color terminals
The other major players in these enhancements besides myself, Mark Horton
and K. Phong Vo, were Ernie Rice, Ephrayim Naiman and Sam Shteingart.
6) Some specific requests in the article to which this is a followup:
< Terminfo Wish List:
< Support for backtab as a keypad character (maybe even support for tab as a
< keypad character, not just ^I).
Added in SVr3.0. Many additional input keys became supported due to the
large number of terminals in use with word processing systems.
< Support for terminals which allow on screen labels to descibe function
< keys (ie something like lab_f* but allowing a string parameter instead of
< a cursor)
Added in SVr3.0. The curses level offers a set of routines named slk_* for
dealing with the "soft labels"
< Modify pkey_* to allow length of string instead of using just assuming a
< terminating character (eg support for length of string on stack, %l)
Added in SVr3.0 were full support of the additional sprintf() sequences. For
example, to print a string out as exactly 16 characters, one would use the
normal sprintf() sequence of:
%16.16s
< Support sequences to control block mode applications.
< Ability to define re-definable character sets.
I don't think that these have been considered.
< Support colour as well as standard high-lighting modes.
Added in SVr3.2
< Ability to use line drawing character sets (eg a set of commands that will
< emit corners, vertical lines, horizontal lines etc.)
Added in SVr3.0. See above.
-----------------------------------------------------------------------------
I hope some of this information proves useful for someone.
Tony Hansen
att!pegasus!hansen, attmail!tonypeter@ficc.uu.net (Peter da Silva) (09/13/88)
In article <3193@pegasus.UUCP>, hansen@pegasus.UUCP (Tony L. Hansen) writes: > It's been interesting watching the recent discussions about terminfo and > curses, asking about the why's and wherefores, etc. As one of the people who > has been involved in the evolution of terminfo and curses, I thought I'd > add a little bit of real information to the net bandwidth. Fine. I've got some more questions, if you don't mind... > The free-form input format and longer names, however, make it considerably > harder (and slower) to interpret the input file. Nonesense. 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). Also, there isn't much you can do to speed things up that will beat having a TERMCAP environment entry. > 5) I want to define my own capabilites > The user defined terminfo capabilities user0 to user9 were added in SysVr3.1. > You're free to do with these as you will. I want to call my new capability 'Fred'. 5a) I want my users to be able to change their terminfo entries quickly and easily. Right now they have to create their own terminfo directory tree, compile it, and remember to change back when they want to use the standard ones. With TERMCAP they could just edit their environment. No need to fill /usr/tmp up with little terminfo files. 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. 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. -- Peter da Silva `-_-' Ferranti International Controls Corporation. "Have you hugged U your wolf today?" peter@ficc.uu.net
greim@sbsvax.UUCP (Michael Greim) (09/15/88)
In article <1486@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: > > Nonesense. 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). > > Also, there isn't much you can do to speed things up that will beat having > a TERMCAP environment entry. Yes, there is. I have defined some capabilities of my own, some with string values of more than 100 characters (maps of linedrawing/semi- graphic characters). The resulting termcap string got longer than 1024 bytes. I extended this to 2048. The initialization time of curses went up to 1.78 seconds (processor time). This seemed a little bit long to me, so I rewrote the lookup functions for termcap (tgetent). It does the following: - the buffered string is more closely packed, i.e. leading tabs on lines are ommitted - if we read the beginning of a string, and see that it is not the one we are looking for, we skip until beginnings of lines - when we have the string we start sorting it into a list, using the slowest (but quickest to write) algorithm, i.e. shifting the rest of the list (but this is done with bcopy/memcpy) - this is of course repeated until there are no more "tc=" entries, or we have a loop Now, if we are looking for a capability, which is normally only done once, we only have to emply binary search. Normal lookup of capabilities consists of running along the whole strings, stopping at ":" until we have found the capability or we are at the end of the string. Assume the final termcap string is 1000 bytes long, and you have to look up 100 entries (curses searches for more than 100). Then this will result in an average of 50 * 1000 character compares. Wherease binary search in a list with 100 entries will result in, let's say, less than 30 operations. I found that this method reduced the startup time of curses from 1.78 seconds to 0.74 seconds for the first entry in termcap. It also reduced startup if the termcap string was taken from the environment variable TERMCAP, but of course not by this magnitude. (see below) The next step was to provide a program, which writes the resulting list unto a file, and to modify the termcap lookup routine to first look for this file. This is similar to the idea in terminfo to use a compiled format. This reduced the startup time of curses to 0.48 seconds, if the files existed! With some of the above mentioned modifications you can well make the termcap routines faster. Here the measurements again: Initialization time of curry routine initscr in seconds processor time on a SIEMENS PC-MX2, running SINIX v2.1 Standard termcap routines from file /etc/termcap : 1.78 from environment var TERMCAP : 1.64 new termcap routines from file /etc/termcap : 0.74 from environment var TERMCAP : 0.58 from compiled file : 0.48 These dates are to be taken with a grain of salt. The whole termcap entry is in fact split into two files. Part one is in /etc/termcap, Part two (extensions) are in /usr/lib/termlib/cy_*. This was done so that programs, which rely on termcap entries not to be longer the 1024 characters, could still work. If I put the termcap entry into the environment variable then it would get only part one. But curses (CURRY) would still read part two from file. (Yes, I know this is a glitch, but we wanted to be able to use those old programs :-) -mg -- email : greim@sbsvax.informatik.uni-saarland.dbp.de or : ...!uunet!unido!sbsvax!greim voice : +49 681 302 2434 snail : M. Greim, Universitaet des Saarlandes, FB 10 - Informatik, Bau 36, Im Stadtwald 15, D-6600 Saarbruecken 11, West Germany # include <disclaimers/std.h>
hansen@pegasus.UUCP (Tony L. Hansen) (09/16/88)
<> = me
< = Peter da Silva
< Fine. I've got some more questions, if you don't mind...
No problem.
<> The free-form input format and longer names, however, make it considerably
<> harder (and slower) to interpret the input file.
< 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.
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. 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.
< Also, there isn't much you can do to speed things up that will beat having
< a TERMCAP environment entry.
You haven't been doing your homework. Benchmarks run by Mark Horton showed
that the linear algorithms used by the terminfo library and doing a single
read from the file system were considerably faster even than the use of a
TERMCAP environment variable.
This was all reported in the 1982 Usenix proceedings.
<> 5) I want to define my own capabilites
<> The user defined terminfo capabilities user0 to user9 were added in
<> SysVr3.1. You're free to do with these as you will.
<I want to call my new capability 'Fred'.
This I can't help you with.
< 5a) I want my users to be able to change their terminfo entries quickly
< and easily. Right now they have to create their own terminfo directory
< tree, compile it, and remember to change back when they want to use the
< standard ones. With TERMCAP they could just edit their environment. No
< need to fill /usr/tmp up with little terminfo files.
Here is chgtinfo.sh:
TERMINFO=/tmp/tinfo.$$; export TERMINFO
T1=`expr "$TERM" : '\(.\)'`
mkdir $TERMINFO $TERMINFO/$T1
cp /usr/lib/terminfo/$T1/$TERM $TERMINFO/$T1
echo "${TERM}X," "$@" "use=$TERM," > $TERMINFO/ti
tic $TERMINFO/ti > /dev/null 2>&1
ln $TERMINFO/$T1/${TERM}X $TERMINFO/$T1/$TERM
echo $TERMINFO
One modifies their terminfo entry like this (this adds auto_left_margin and
auto_right_margin to the current terminfo entry):
TERMINFO=`chgtinfo am, bw,`
To unset this, one does this:
rm -r $TERMINFO
unset TERMINFO
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.
With both termcap and terminfo, you have to remember to change back when you
want to use the standard ones. I don't see an advantage on other side.
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.
< 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.
Actually, better yet would be a standard set of database routines available
on all systems.
< 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/?
Egrep also works fine on the files under /usr/lib/terminfo.
Tony Hansen
att!pegasus!hansen, attmail!tonyidall@augean.OZ (Ian Dall) (09/16/88)
In article <1486@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
->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.
I think "ls" would do pretty well!
--
Ian Dall life (n). A sexually transmitted disease which afflicts
some people more severely than others.
idall@augean.ozchris@mimsy.UUCP (Chris Torek) (09/16/88)
In article <3194@pegasus.UUCP> hansen@pegasus.UUCP (Tony L. Hansen) writes: >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. The second is often done without the overhead of a function call, too. If the compiler will not expand strcmp in line, in time-sensitive code I just use a macro, or compare the first characters directly. >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. The search for each >capability starts over again at the very beginning of the entry. This need not be the case. One obvious solution is to sort the entries. Another, perhaps better, is to hash them: I imagine a simple hash based on the first character and the length of the capability would work quite well. Compiling is not necessarily wrong: after all, we do it all the time with other things. It is, however, an extreme approach, and ought to be considered carefully. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
les@chinet.UUCP (Leslie Mikesell) (09/17/88)
In article <3194@pegasus.UUCP> hansen@pegasus.UUCP (XT1554000-Tony L. Hansen;LZ 3B-315;3207) writes: >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. 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. Am I missing something here or couldn't this problem be solved by simply grabbing everything you want in one pass through the termcap entry. That is, sort the list of capnames you want, find the first name from the termcap entry, do a binary search on the list you want and grab the entry if you need it. This would not even require allocating storage for the entire entry. And it would not preclude putting unknown names in the entry. >You haven't been doing your homework. Benchmarks run by Mark Horton showed >that the linear algorithms used by the terminfo library and doing a single >read from the file system were considerably faster even than the use of a >TERMCAP environment variable. It probably doesn't take much to beat a linear search. However, speed isn't the whole issue here. How about taking many times the disk space (a significant difference on small machines), especially if you keep the source files around, plus needing the compiler and decompiler. ><> 5) I want to define my own capabilites ><> The user defined terminfo capabilities user0 to user9 were added in ><> SysVr3.1. You're free to do with these as you will. Ok, suppose you have an assortment of machines ranging from SysVr2 to SysVr3.2. You can move the binaries around, but moving the binary from an older release loses the new capabilities. Moving a newer release to an older will work, but if you decompile, modify and re-compile you can't move it back without losing the new capabilities. >< 5a) I want my users to be able to change their terminfo entries quickly >< and easily. > [shell script to make a terminfo file deleted] That was supposed to be an improvement over setting an environment variable??? >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. I would expect it to be done for you by the programs that want to emulate some terminal type in a window or across a network. I don't see anything inherent in the terminfo capabilities that would have prevented using a format compatible with environment entries. Les Mikesell
peter@ficc.uu.net (Peter da Silva) (09/19/88)
In article <3194@pegasus.UUCP>, hansen@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@ficc.uu.net
allbery@ncoast.UUCP (Brandon S. Allbery) (09/24/88)
As quoted from <3194@pegasus.UUCP> by hansen@pegasus.UUCP (Tony L. Hansen): +--------------- | < = Peter da Silva | | < 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. +--------------- If you want to use both curses and a custom termcap file, you need either (a) source or (b) ar, a binary editor, and either guts or Valium. Since I'm unimpressed with termcap anyway, I use either a passwd-style file or one of my standard libraries, as described in an earlier message. Although I have modified termcap when I was in a hurry and didn't have my libraries on the system in question (I used guts). Neither termcap nor terminfo is perfect. Terminfo is better from my standpoint because it's so much faster than termcap even in the environment when starting editors -- and yes, I *have* tested this. But the binary file is something of a pain. I suspect I could convert my terminfo-style library into something that allowed both binary and text formats with relatively little trouble, so it wouldn't be impossible to solve. ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc "Don't discount flying pigs before you have good air defense." -- jvh@clinet.FI
allbery@ncoast.UUCP (Brandon S. Allbery) (09/27/88)
As quoted from <1536@ficc.uu.net> by peter@ficc.uu.net (Peter da Silva): +--------------- | In article <3194@pegasus.UUCP>, hansen@pegasus.UUCP (Tony L. Hansen) writes: | > <> = tony | > < = peter | | > < 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. +--------------- I have yet to see a termcap manual that described a variable called "tent". Which leaves us back to requiring source. ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to <backbone>!sources-misc comp.sources.misc is moving off ncoast -- please do NOT send submissions direct ncoast's days are numbered -- please send mail to ncoast!system if you can help