mike@whuxl.UUCP (BALDWIN) (05/16/86)
>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 Oh, reading a 70K file and parsing it each time is faster than reading in an already-parsed binary file? I find terminfo a huge step forwards in design. >-- 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. Give me a break. The format is documented and easy to parse, and anyway, with SVR3 you get the infocmp(1) program, which dumps a terminfo entry in a form suitable for editing and recompiling via tic(1). What the hell more do you want? And my 5620 terminfo entry works fine (I'm using it right now). >Termcap isn't as expressive, perhaps, but I can write and >modify termcap descriptions easily. $ infocmp >file; ed file; tic file Real difficult. Terminfo just beats the pants off termcap; the sooner termcap disappears the better. -- Michael Baldwin (not the opinions of) AT&T Bell Laboratories {at&t}!whuxl!mike
keith@enmasse.UUCP (Keith Crews) (05/19/86)
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? Is there a further list that describes other entries that curses will use, if provided, that will allow it to use all its smarts? Having such a list would make the preparation of terminfo descriptions much easier, since it hard to figure out which of the 200 or so terminfo capabilities are actually going to be required by a particular program that uses a subroutine library (such as curses) that was written by someone else. Keith Crews
ken@njitcccc.UUCP (Kenneth Ng) (05/19/86)
In article <1119@whuxl.UUCP>, mike@whuxl.UUCP (BALDWIN) writes: > Give me a break. The format is documented and easy to parse, and anyway, > with SVR3 you get the infocmp(1) program, which dumps a terminfo entry > in a form suitable for editing and recompiling via tic(1). What the > hell more do you want? And my 5620 terminfo entry works fine (I'm using > it right now). System five release three? That is a new one on me. Anyway, how about all those people who have release 2 who don't have infocmp(1)? I just ran a search of the entire file system and didn't find anything by that name. Furthermore, how about putting some more meaningful error messages into tic(1)? I have yet to find a single error message run tic with -v9. Terminfo is a great product, but it would be really useful if there were a utility to convert ALL of termcap into terminfo, especially the translations into RPN in the cursor addressing. -- Kenneth Ng: uucp(unreliable) ihnp4!allegra!bellcore!njitcccc!ken bitnet(prefered) ken@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"
earlw@pesnta.UUCP (Earl Wallace) (05/20/86)
[Reference to article <1119@whuxl.UUCP> from mike@whuxl.UUCP] ... >>-- 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. > >Give me a break. The format is documented and easy to parse, and anyway, >with SVR3 you get the infocmp(1) program, which dumps a terminfo entry >in a form suitable for editing and recompiling via tic(1). What the >hell more do you want? And my 5620 terminfo entry works fine (I'm using >it right now). > >>Termcap isn't as expressive, perhaps, but I can write and >>modify termcap descriptions easily. > >$ infocmp >file; ed file; tic file >Real difficult. Terminfo just beats the pants off termcap; >the sooner termcap disappears the better. >-- > Michael Baldwin > (not the opinions of) AT&T Bell Laboratories > {at&t}!whuxl!mike "what the hell more do you want?" Sounds like a nasty attitude Mr. Baldwin. The terminfo files may be easy to parse but why should I go thru all that bother when it's much easier for AT&T to provide a program to dump the terminfo file? Now we find out (from you) that AT&T does have a program (infocmp) for the not-yet-released System V.3. Does this mean AT&T recognized the need for such a program? I think it does. So what's your problem Mr. Baldwin? Why are you jumping down the throat of some frustrated user? This is not a good sign of your understanding of the Customers' needs. You do understand that (no customers = no jobs) don't you? You know, we really can walk across the street now, and we just may if attitudes like yours don't improve real quick.
ken@njitcccc.UUCP (Kenneth Ng) (05/20/86)
In article <299@enmasse.UUCP>, keith@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) ken@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"
chris@umcp-cs.UUCP (Chris Torek) (05/21/86)
In article <162@njitcccc.UUCP> ken@njitcccc.UUCP (Kenneth Ng) writes: >In article <299@enmasse.UUCP>, keith@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: chris@mimsy.umd.edu
mike@whuxl.UUCP (BALDWIN) (05/21/86)
>"what the hell more do you want?" Sounds like a nasty attitude Mr. Baldwin. I apologise for the snipey remarks. >The terminfo files may be easy to parse but why should I go thru all that >bother when it's much easier for AT&T to provide a program to dump the >terminfo file? I agree. >Now we find out (from you) that AT&T does have a program >(infocmp) for the not-yet-released System V.3. Does this mean AT&T >recognized the need for such a program? Of course. That's why I mentioned them. >So what's your >problem Mr. Baldwin? Why are you jumping down the throat of some >frustrated user? Because the frustrated user was ranting and raving. If I flame about you, you have every right not to be civil to me. >This is not a good sign of your understanding of the >Customers' needs. I understood exactly what the needs were. I just didn't like how they were conveyed, and the misinformation along with it. The user gets to yell and scream, but I don't? Feh. If you talk reasonable, so will I. -- Michael Baldwin (not the opinions of) AT&T Bell Laboratories {at&t}!whuxl!mike
mesans@uvicctr.UUCP (mesans) (05/22/86)
References:
Thinking of Terminfo, I have a question about using it on a Berkley
4.2 System (Vax 11/780). Just over a year ago we got a copy of CCA
EMACS here. When I have my term type set to anything but VT100 however
(there are a few other valid terminal types, but we don't have them),
it screems at me that it cannot find a terminfo entry (which is
reasonable, considering we are using termcap instead). I have my
own VT220 termcap entry (uses Highlight, instead of inverse, etc.),
which I much prefer. Does anyone have any suggestions, or am I stuck?
Many thanks,
S. John Banner
PS. Will sumarize if intersest is there. sjb.
CCSJB at UVVM (Bitnet)
uw-beaver!ssc-vax!uvicctr (UUCP) (I hope this is right, I am new
at this, the Bitnet address is).nelsons@psu-cs.UUCP (05/22/86)
> in an already-parsed binary file? I find terminfo a huge step forwards > in design. > ... > > Give me a break. The format is documented and easy to parse, and anyway, > with SVR3 you get the infocmp(1) program, which dumps a terminfo entry > in a form suitable for editing and recompiling via tic(1). What the > hell more do you want? And my 5620 terminfo entry works fine (I'm using > it right now). > ... > > $ infocmp >file; ed file; tic file > Real difficult. Terminfo just beats the pants off termcap; > the sooner termcap disappears the better. > -- > Michael Baldwin > (not the opinions of) AT&T Bell Laboratories > {at&t}!whuxl!mike FLAME ON: Unfortunately, not all of us happen to have SVR3, nor do we have infocmp(1) or anything similar. But that's not my biggest beef with tic(1). I don't know if anyone else has had this problem, but when tic(1) is fed a file it doesn't like, it very quietly *unlinks everything under /usr/lib/terminfo*!! I do *not* like having to clean up after tic throws up on my filesystem, and I definitly do not consider that a "huge step forward in design". Flame off. By the way, if anyone can send me an untic program, I would be much obliged... Shannon Nelson Portland State University Portland, OR ...tektronix!psu-cs!nelsons
jay@isis.UUCP (Jay Batson) (05/23/86)
In article <1119@whuxl.UUCP> mike@whuxl.UUCP (BALDWIN) writes about termcap v terminfo, responding to the following complaint about the difficulty of modifying terminfo: >>-- PARICULARLY when AT&T then doesn't include the >>sources to the terminfo descriptions. As shipped, the description for >>the DMD5620 is noticibly broken.... > >Give me a break. The format is documented and easy to parse, and anyway, >with SVR3 you get the infocmp(1) program, which dumps a terminfo entry >in a form suitable for editing and recompiling via tic(1). What the >hell more do you want? And my 5620 terminfo entry works fine (I'm using >it right now). Of course. And the world is supposed to come to a halt and not write/modify any more terminal definitions (read "buy only terminals which AT&T wants to care about) until SVR3 is widely distributed. Come now - how many SV/SVR2 UNIX's are out there now? More importantly, do you have to deal with a customer who calls and says "this terminal screen is doing strange things"???? Lots of us out here do, and for the realistic future, termcap stays THE terminal database for my (current) money. Jay Batson Energy Logic Systems, Inc. seismo!hao!isis!jay hplabs!../
ken@njitcccc.UUCP (Kenneth Ng) (05/23/86)
In article <1624@umcp-cs.UUCP>, chris@umcp-cs.UUCP (Chris Torek) writes: > In article <162@njitcccc.UUCP> ken@njitcccc.UUCP (Kenneth Ng) writes: > >In article <299@enmasse.UUCP>, keith@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#') [CT] I thought I said that? Perhaps I should have explained it better. > [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. I stand corrected on "Stonn", it does sound closer to his actual name. The quotes are, after the battle: Spock: "Explain" ToPring: "Specify" Spock: "Why did you choose the battle, and my captain as your victor?" ToPring: "I wanted Stonn, Stonn wanted me." Spock: "I fail to see the logic in prefering Stonn over me." > But I do recall this (probably inexactly): `You may find that *having* > something is not quite so pleasing a thing as *wanting* it.' This is correct. -- Kenneth Ng: uucp(unreliable) ihnp4!allegra!bellcore!njitcccc!ken bitnet(prefered) ken@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 Stonn over me" Number 5: "I need input"
geoff@desint.UUCP (05/24/86)
In article <1124@whuxl.UUCP> mike@whuxl.UUCP (BALDWIN) writes: > The user gets to yell and scream, but I don't? Feh. > If you talk reasonable, so will I. Not to sound like an IBM fan (I'm not), but the reason IBM is #1 is because they let the user yell and scream, and they talk reasonably back. It's called "smoothing ruffled feathers". It may be satisfying to yell back, but that's just going to make the customer go away. IBM didn't get to be #1 in sales by losing customers. I've directed followups to this to net.unix only, on the theory that the unix-wizards and info-terms folks don't want to be bothered. -- Geoff Kuenning {hplabs,ihnp4}!trwrb!desint!geoff
dan@prairie.UUCP (Daniel M. Frank) (05/26/86)
In article <218@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: >Not to sound like an IBM fan (I'm not), but the reason IBM is #1 is because >they let the user yell and scream, and they talk reasonably back. It's called >"smoothing ruffled feathers". It may be satisfying to yell back, but that's >just going to make the customer go away. IBM didn't get to be #1 in >sales by losing customers. Just an observation by someone who has tried to get some fairly simple technical information out of IBM support: everyone I talk to at IBM is unfailingly polite, and abysmally ignorant. People at IBM kept asking me whether Xenix was a hardware product. One fellow I know tried for a couple days to get some information; he was shuffled from one 800 number to another. He was trying to get a PC question answered. Someone gave him a mainframe support number. When he tried to explain to them that he didn't own a mainframe, they gave him an 800 number for someone who could sell him one! In short, the ideal would be to talk to someone polite and knowledge- able. My next choice, though, is someone abrasive and knowledgeable. Most folks, in my experience, aren't irate when they START trying to get support. They are irate after talking to a bunch of ignorami, polite or not, for a few hours. -- Dan Frank ... uwvax!geowhiz!netzer!prairie!dan -or- dan@caseus.wisc.edu
mkr@mmm.UUCP (MKR) (06/06/86)
In article <134@prairie.UUCP> dan@prairie.UUCP (Daniel M. Frank) writes: > >People at IBM kept asking me >whether Xenix was a hardware product. That reminds me of the time... Just this year I met a systems ananlyst from the mainframe world. As we were telling each other what our areas of experience were, I said that I was strongest in Unix. He got a puzzled look on his face, paused, and said, "Unix? Is that the new Univac computer?" --MKR