Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site bunker.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!ittatc!bunker!ricker
From: ric...@bunker.UUCP (James A. Ricker)
Newsgroups: net.unix-wizards,net.unix
Subject: Terminfo()--Ideas needed. System V
Message-ID: <1135@bunker.UUCP>
Date: Tue, 29-Apr-86 16:19:45 EDT
Article-I.D.: bunker.1135
Posted: Tue Apr 29 16:19:45 1986
Date-Received: Fri, 2-May-86 07:58:20 EDT
Reply-To: ric...@bunker.UUCP (James A. Ricker)
Organization: Bunker Ramo, Trumbull Ct
Lines: 7
Keywords: curses,termcap,terminfo,System V
Summary: Need Ideas on how to handle terminals that have more than 10 F keys
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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!mcnc!ecsvax!bet
From: b...@ecsvax.UUCP (Bennett E. Todd III)
Newsgroups: net.unix-wizards,net.unix,net.info-terms
Subject: Re: Terminfo()--Ideas needed. System V & Re: request for extended Termcap description.
Message-ID: <1553@ecsvax.UUCP>
Date: Wed, 14-May-86 13:36:13 EDT
Article-I.D.: ecsvax.1553
Posted: Wed May 14 13:36:13 1986
Date-Received: Thu, 15-May-86 08:27:09 EDT
References: <1135@bunker.UUCP> <155@molihp.UUCP> <2774@pegasus.UUCP>
Reply-To: b...@ecsvax.UUCP (Bennett E. Todd III)
Distribution: net
Organization: Duke University Computation Center
Lines: 24
Keywords: terminfo,termcap
In article <2...@pegasus.UUCP> han...@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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 5/22/85; site cbosgd.UUCP
Path: utzoo!watmath!clyde!cbosgd!mark
From: m...@cbosgd.UUCP (Mark Horton)
Newsgroups: net.unix-wizards,net.unix,net.info-terms
Subject: Re: Terminfo()--Ideas needed. System V
Message-ID: <2145@cbosgd.UUCP>
Date: Sun, 18-May-86 01:54:13 EDT
Article-I.D.: cbosgd.2145
Posted: Sun May 18 01:54:13 1986
Date-Received: Mon, 19-May-86 04:42:51 EDT
References: <1135@bunker.UUCP> <155@molihp.UUCP> <2774@pegasus.UUCP> <1553@ecsvax.UUCP>
Organization: AT&T Bell Laboratories, Columbus, Oh
Lines: 69
In article <2...@pegasus.UUCP> han...@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 <1...@ecsvax.UUCP> b...@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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 5/22/85; site cbosgd.UUCP
Path: utzoo!watmath!clyde!cbosgd!mark
From: m...@cbosgd.UUCP (Mark Horton)
Newsgroups: net.unix-wizards,net.unix,net.info-terms
Subject: Re: Terminfo()--Ideas needed. System V
Message-ID: <2146@cbosgd.UUCP>
Date: Sun, 18-May-86 02:16:26 EDT
Article-I.D.: cbosgd.2146
Posted: Sun May 18 02:16:26 1986
Date-Received: Mon, 19-May-86 04:43:06 EDT
References: <1135@bunker.UUCP> <155@molihp.UUCP> <2774@pegasus.UUCP> <1553@ecsvax.UUCP>
Organization: AT&T Bell Laboratories, Columbus, Oh
Lines: 18
Keywords: terminfo,termcap
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.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!columbia!caip!andromeda!njitcccc!ken
From: k...@njitcccc.UUCP (Kenneth Ng)
Newsgroups: net.unix-wizards,net.unix,net.info-terms
Subject: Re: terminfo, termcap, etc
Message-ID: <162@njitcccc.UUCP>
Date: Tue, 20-May-86 09:38:31 EDT
Article-I.D.: njitcccc.162
Posted: Tue May 20 09:38:31 1986
Date-Received: Fri, 23-May-86 22:39:04 EDT
References: <1135@bunker.UUCP> <155@molihp.UUCP> <2774@pegasus.UUCP> <299@enmasse.UUCP>
Distribution: net
Organization: NJ Inst of Tech., Newark NJ
Lines: 27
Summary: Partial miminal list
In article <2...@enmasse.UUCP>, ke...@enmasse.UUCP (Keith Crews) writes:
> While we are on the subject of terminfo, does anyone know of a documented
> list of terminfo entries that are sufficient to allow curses to work
> properly, if not optimally, in all cases?
I have found that the minimal requirements are (I think): col
and row numbers, clear screen, cursor addressing, and indexing.
By indexing Un*x means the control sequence to scroll the screen
up a line. About a month back I played with writing one from
scratch, and the indexing feature was the one feature I left
out, and vi always used the open mode till I put it in. But
of course the manual does not say what the minimal requirements
are, I guess they just assume you can read minds.
Just a clarification: by scrolling up a line I mean what happens
on a dumb terminal when you reach the bottom of the screen and
type a <cr> or a <lf>.
--
Kenneth Ng: uucp(unreliable) ihnp4!allegra!bellcore!njitcccc!ken
bitnet(prefered) k...@njitcccc.bitnet
New Jersey Institute of Technology
Computerized Conferencing and Communications Center
Newark, New Jersey 07102
Vulcan jealousy: "I fail to see the logic in prefering Stan over me"
Number 5: "I need input"
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!seismo!umcp-cs!chris
From: ch...@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.unix-wizards,net.unix,net.info-terms
Subject: Re: terminfo, termcap, etc
Message-ID: <1624@umcp-cs.UUCP>
Date: Wed, 21-May-86 02:13:27 EDT
Article-I.D.: umcp-cs.1624
Posted: Wed May 21 02:13:27 1986
Date-Received: Sat, 24-May-86 02:14:58 EDT
References: <1135@bunker.UUCP> <155@molihp.UUCP> <2774@pegasus.UUCP> <299@enmasse.UUCP> <162@njitcccc.UUCP>
Reply-To: ch...@maryland.UUCP (Chris Torek)
Distribution: net
Organization: University of Maryland, Dept. of Computer Sci.
Lines: 83
In article <1...@njitcccc.UUCP> k...@njitcccc.UUCP (Kenneth Ng) writes:
>In article <2...@enmasse.UUCP>, ke...@enmasse.UUCP (Keith Crews) writes:
>>While we are on the subject of terminfo, does anyone know of a
>>documented list of terminfo entries that are sufficient to allow
>>curses to work properly, if not optimally, in all cases? [KC]
>I have found that the minimal requirements are (I think): col
>and row numbers, clear screen, cursor addressing, and indexing.
>By indexing Un*x means the control sequence to scroll the screen
>up a line. [KN]
Actually, at least under 4BSD, vi requires:
1) cursor motion, including EITHER:
a) up and left and absolute, OR
b) up, down, left, and right
2) clear screen
3) screen size (`co#' and `li#')
4BSD vi assumes a line feed from the last line will force a scroll.
I once worked with a terminal emulator for which this was not true;
it was rather painful. (Adding `ns', `terminal is a CRT but cannot
scroll', makes vi use open mode: workable but unpleasant.)
4BSD curses may have a different set of minimums; at any rate I
remember *something* needed a clear-to-end-of-line as well.
Also, some attributes may force others to be required. For example,
`db' implies a need for `cd=', though vi will iterate `ce=' if it
must. (It may even use blanks if necessary; I have never tried it.)
Moreover, some attributes (e.g., `am') will cause what look like
random trouble if they are specified incorrectly. If you want
instead to know which capabilites are *examined*, well, again,
that depends on the program.
My own termcap Emacs screen driver has similar (though not quite
identical) requirements as vi; but it currently *uses* all of these:
Strings (`cl='):
al bc cd ce cl ch cm cr cv dc dl dm ds ed ei ho ic im ip
pc ll nd nl se so ta te ti ue up us vb ve vs
Numerics (`co#'):
co li sg tw ug
Flags (`am'):
MT am bs db hz in km mi ms nc nn rn ul xn xs xt
(Alas, it is missing the new AL, DL, etc. entries; nor will it use
`cs='. `rn', `nn', `tw#', and `ds=' are locals.)
I just found vi's strings and flags too:
al bc bt cd ce cl cm cr cs dc dl dm do ed ei k0 k1 k2 k3 k4
k5 k6 k7 k8 k9 ho ic im ip kd ke kh kl kr ks ku ll nd nl pc
rc sc se sf so sr ta te ti up vb vs ve AL DL UP DO LE RI
and
am bs da db eo hc hz in mi nc ns os ul xb xn xt xx
respectively.
>But of course the manual does not say what the minimal requirements
>are, I guess they just assume you can read minds.
I seem to recall seeing a list of requirements somewhere. Perhaps
it was in a bit of source code. The real problem, though, is that
the `minimal' set depends upon the program, and could change between
system releases; and writing a complete description is always
sufficient, if time-consuming.
[And a bit off the beaten track---in fact in .signature territory:]
>Vulcan jealousy: "I fail to see the logic in prefering Stan over me"
Actually, it was `Stonn'; I am not sure about the rest of the quote.
But I do recall this (probably inexactly): `You may find that *having*
something is not quite so pleasing a thing as *wanting* it.'
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP: seismo!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: ch...@mimsy.umd.edu
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 5/22/85; site cbosgd.UUCP
Path: utzoo!watmath!clyde!cbosgd!mark
From: m...@cbosgd.UUCP (Mark Horton)
Newsgroups: net.unix-wizards,net.unix,net.info-terms
Subject: Re: Terminfo()--Ideas needed. System V
Message-ID: <2171@cbosgd.UUCP>
Date: Tue, 27-May-86 01:08:33 EDT
Article-I.D.: cbosgd.2171
Posted: Tue May 27 01:08:33 1986
Date-Received: Wed, 28-May-86 01:45:13 EDT
References: <1135@bunker.UUCP> <155@molihp.UUCP> <2774@pegasus.UUCP> <1553@ecsvax.UUCP> <2146@cbosgd.UUCP> <1596@ecsvax.UUCP>
Organization: AT&T Bell Laboratories, Columbus, Oh
Lines: 66
Keywords: terminfo,termcap
In article <1...@ecsvax.UUCP> b...@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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 5/22/85; site cbosgd.UUCP
Path: utzoo!watmath!clyde!cbosgd!mark
From: m...@cbosgd.UUCP (Mark Horton)
Newsgroups: net.unix-wizards,net.unix,net.info-terms
Subject: Re: Terminfo()--Ideas needed. System V
Message-ID: <2187@cbosgd.UUCP>
Date: Sat, 31-May-86 16:40:44 EDT
Article-I.D.: cbosgd.2187
Posted: Sat May 31 16:40:44 1986
Date-Received: Sun, 1-Jun-86 09:42:38 EDT
References: <691@bu-cs.UUCP>
Organization: AT&T Bell Laboratories, Columbus, Oh
Lines: 55
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