Archived information about "terminfo", "termcap", and "curses". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Additional related information appears here: http://www.cs.utk.edu/~shuford/terminal/unix_terminal_news.txt ////////////////////////////////////////////////////////////////////////////// Bill Joy, in his prolific days at the Berkeley campus of the University of California, developed the "termcap" database so that the "vi" editor could be easily supported on lots of different kinds of character-cell video terminals. Also archiving excerpted discussion about "terminfo", the AT&T System V Unix equivalent terminal-information database, and some information on the Unix/Linux "curses" and "ncurses" libraries. The functions of the "curses" package are part of the X/Open Unix Standard: http://www.opengroup.org/pubs/catalog/c610.htm An introduction to using "termcap" in BSD Unix appears here: http://www.fnal.gov/reports/products/xemacs/v19_14/termcap_1.html#SEC1 [2006-04-18: fnal.gov link still valid] ////////////////////////////////////////////////////////////////////////////// A source of useful information is this book termcap & terminfo by John Strang, Linda Mui & Tim O'Reilly 3rd Edition April 1988 270 pages, ISBN: 0-937175-22-6, $21.95 U.S. [ORA catalog description follows] While termcap and terminfo are no longer as important as they once were, due to the growth of the X terminal market and increased standardization among ASCII terminals, handling different terminal types can still be a headache for system administrators. The termcap and terminfo databases are UNIX's solution to the difficulty of supporting many terminals without writing special drivers for each terminal. Termcap (BSD) and terminfo (System V) describe the features of hundreds of terminals, together with a library of routines that allow programs to use those capabilities. This book documents hundreds of capabilities and syntax for termcap and terminfo, writing and debugging terminal descriptions, and terminal initialization. In the United States and Canada, the book may be ordered from O'Reilly & Associates, Inc. 103-Aa Morris Street Sebastopol, CA 95472 Internet e-mail: order@ora.com WATS voice phone: 1-800-998-9938 POTS voice phone: +1 707/829-0515 POTS fax phone: +1 707/829-0104 Or see: http://www.amazon.com/exec/obidos/ISBN=0937175226 A review of the book appears below. ...RSS ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.dcom.telecom Path: cs.utk.edu!gatech!howland.reston.ans.net!spool.mu.edu!telecom-request Message-ID: Organization: TELECOM Digest Sender: telecom@eecs.nwu.edu Approved: telecom@eecs.nwu.edu X-Telecom-Digest: Volume 13, Issue 789, Message 1 of 14 Date: 29 Nov 1993 13:06 -0600 From: Rob Slade Subject: Book Review: "Termcap and Terminfo" by Strang/Mui/O'Reilly BKTERMCP.RVW 931102 O'Reilly & Associates, Inc. 103 Morris Street, Suite A Sebastopol, CA 95472 800-998-9938 707-829-0515 fax: 707-829-0104 info@ora.com "Termcap and Terminfo", Strang/Mui/O'Reilly, 1991, 0-937175-22-6 I remember a certain federal government EDP office being very smug about the fact that they were able to allow us to use WordStar on a Turbo DOS system, with VT100s, as well as whatever oddball terminals they had. Of course, we had to invoke the program with "WSVT100" since the program files were completely different, compiled with two different drivers. (For those of you who find it difficult to install WordPerfect, you would have *hated* early MS-DOS versions of WordStar, with many settings required during the installation process harking back to the various terminal options of previous systems.) I also recall getting the (then) brand new VT320 terminals in another VAX shop. Well pleased with having the latest technology, I hooked it up, logged on, started All-in-1 ... and was presented with the TTY menu. The VT320 was so new at that time that the All-in-1 driver had not yet been completed. Such is life in the technological fast lane. Some programs simply print line after line of information, seeing the screen as an infinitely long roll of typewriter paper. Most of the more interesting applications, however, want more than that. They want to be able to "paint" a screen, use areas of it for windows, change text depending upon the user's interaction, allow choices by highlighting items from a menu, and so forth. To do this, the program needs to know the functions and commands for the terminal. Therefore, you need a different program, or a different driver, for each terminal type to be used. The vi editor is now considered to be difficult, awkward and unfriendly. When Bill Joy first wrote it, though, it was a remarkable advance on what was available. Therefore, there was a great demand to port it to different systems ... and *many* different terminals. In true UNIX community "roll your own" fashion, Joy developed a system whereby a library of terminal capability subroutines could be linked to a database describing the commands for each terminal. This system, because it dealt with *ter*minal *cap*abilities was referred to as termcap. Termcap is used in BSD versions of UNIX; a slightly variant version called "terminfo" is used in System V. Curses, a more modern subroutine library, can also use termcap terminal database entries. Although intended for use by system administrators, this book is so very well designed and written that it makes termcap and terminfo accessible to reasonably computer-literate users as well. Writing device drivers is hard, but the difficulty tends to lie in the availability of tools, and the time needed to cover all the bases. This book points to, and explains, the tools, and allows users to experiment with what is important to them on their own time. Part one, chapters one to six, is a tutorial covering the basic concepts, syntax, environment variables and basic commands. Part two, chapters seven to sixteen, is basically the termcap language reference. Appendices cover vi capabilities, access from C programs, and a cross-reference. You may be fortunate enough to have a full and debugged terminal database. If not, and particularly if your users insist on a variety of PC terminal emulators of questionable "accuracy", then you need this book. If nothing else, you can give it to the user who insists on "Joe's Modem Supreme Program" and tell him to figure it out for himself. copyright Robert M. Slade, 1993 BKTERMCP.RVW 931102 Permission granted to distribute with unedited copies of the TELECOM Digest and associated newsgroups/mailing lists. DECUS Canada Communications, Desktop, Education and Security group newsletters Editor and/or reviewer ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733 DECUS Symposium '94, Vancouver, BC, Mar 1-3, 1994, contact: rulag@decus.ca ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals,comp.unix.programmer,comp.unix.questions, comp.unix.sco.programmer Path: cs.utk.edu!nntp.memphis.edu!nntp.msstate.edu!cssun.mathcs.emory.edu !swrinde!howland.reston.ans.net!newsfeed.internetmci.com!in1.uu.net !news.gun.de!umunk.GUN.de!udo Subject: Re: Color terminal terminfo capabilities Message-ID: <9510255049@umunk.GUN.de> From: udo@umunk.GUN.de (Udo Munk) Date: Wed, 25 Oct 95 14:14:46 +0100 References: <46gg2o$p3@adam.telalink.net> Kelly Beard (kbeard@trendar.com) wrote: : : I have an assignment to integrate the Wyse 325 terminal into our software. : Our company would like for our customers to have color screens for various : reasons. My problem is that I, being a conscientious programmer, would like : to use code that is portable, at least on UNIX/Xenix. This term is backwards : compatible with the Wyse 60, so that part is easy. However, we access : terminal capabilities : through terminfo. The only reference I have is the Nutshell book "termcap & : terminfo", and it does not cover color terminals, and their associated : capabilities. : My dilemma? Where can I get info on the color capabilities? It isn't : documented : in the SCO manuals, nor in the Wyse 325 manuals. I will resort to hard-coding : the escape sequences if necessary, but there is a better way. : If you can point me too the proper references, or supply me with appropriate : terminfo descriptions with explanation, I would be grateful. You should get the following book: UNIX Curses Explained by Berny Goodheart Prentice Hall, ISBN 0-13-931957-3 It's much better than the Nutshell you have and it also explains how to use the color capabilities from both, curses and terminfo low level. And it's documented in the SCO manuals, see the curses and terminfo manual pages, the first one has a complete chapter for color capability programming, at least in the SCO UNIX docs, don't know the Xenix ones. -- Udo Munk udo@umunk.GUN.de, CIS: 100021,2515 .............................................................................. [As of 2003, Goodheart's book is out of print. Some used copies may still be available, however.] ////////////////////////////////////////////////////////////////////////////// Message-ID: <3738af30@news.nwlink.com> References: <7h2ttb$324$1@nntp9.atl.mindspring.net> Organization: Northwest Link Date: Tue, 11 May 1999 15:25:13 -0500 From: Peter Smith Newsgroups: comp.terminals Subject: Re: Creating a vt100 Terminal Application (a question about how best to write new code for use with a VT100 or similar video terminal) There are pretty much two basic choices: (a) use NCURSES. There's O'Reilly documentation for it now, so you don't have to puzzle it out from the man pages any more! [UPDATE: see below] (b) Just spit out the escape sequences If it's a small, simple application, I'd be tempted to use plan (b) -- it may well be simpler and quicker. The down side is that supporting different terminals. In general, the differences between windows and terminals are: (a) terminals remember what you told them. Once you output a string to be displayed, you'll never be asked to display it again just because the user covered and uncovered the window (b) the primary action is, "go to a certain spot and display a string" (c) the primay fancy action is to use a scrolling region -- part of the text stays still, the rest will scroll. (d) the best way to make your boss think you're special is to color-code the output. Just output a color-change escape sequence, and shazam! a very pretty display. Trust me on this one: you can sweat for a week to make a display, and get a big "so what" from the boss. Spend five minutes adding color, and get a pat on the back. Peter Smith former terminal sequence hotshot for RS/1 ////////////////////////////////////////////////////////////////////////////// Date: Wed, 12 May 1999 00:15:03 GMT From: "T.E.Dickey" Newsgroups: comp.terminals Subject: Re: Creating a vt100 Terminal Application Peter Smith wrote: > There are pretty much two basic choices: > (a) use NCURSES. There's O'Reilly documentation for it now, so you don't > have to puzzle it out from the man pages any more! I'm puzzled--where does O'Reilly have documentation for ncurses? -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey ////////////////////////////////////////////////////////////////////////////// Message-ID: References: <7h2ttb$324$1@nntp9.atl.mindspring.net> <3738af30@news.nwlink.com> <3739bdd7@news.nwlink.com> Date: Thu, 13 May 1999 01:25:07 GMT From: "T.E.Dickey" Newsgroups: comp.terminals Subject: Re: Creating a vt100 Terminal Application Peter Smith wrote: > Here's the web site: > http://www.oreilly.com/catalog/curses/ > and the book information: > Programming with curses > By John Strang > 1st Edition 1986 > 0-937175-02-1, Order Number: 021 > 76 pages, $12.95 > Well, ok, so it's for "curses" and not "ncurses". There's also a termcap > and terminfo book. I have both. The termcap/terminfo book is useful, the curses book not. (It predates color and other interesting things). -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey/ ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Path: cs.utk.edu!darwin.sura.net!lhc!adm!smoke!gwyn Message-ID: <19982@smoke.brl.mil> References: Organization: U.S. Army Ballistic Research Lab, APG MD. Date: 6 May 1993 16:33:07 GMT From: gwyn@smoke.brl.mil (Doug Gwyn) Subject: Re: Know any AT&T Sys V Curses for BSD? In article mbparker@mit.edu writes: > > So has anyone ported the extensions of AT&T curses back into BSD curses, so > BSD can have all the functionality of System V? I've found no such thing > executing ``archie curses''. Thanks you very much for your info, The significant difference is primarily in "terminfo" that replaced "termcap"; the "curses" library is built on top of that. Pavel Curtis did provide a public-domain implementations of terminfo and an associated curses library. Presumably this is archived somewhere, probably on the Prime Time Freeware CD-ROM among others. -- Doug .................................................................. [Archiver's Note: Doug is referring to code that formed the basis for the package known as "ncurses". About "ncurses", Thomas E. Dickey says this: Zeyd Ben-Halim started it from a previous package "pcurses", written by Pavel Curtis. Eric Raymond continued development. Juergen Pfeifer wrote most of the form and menu libraries. I [Dickey] have done most of the configuration work, do most of the testing. Numerous people (more than I know about) contribute fixes. See http://dickey.his.com/ncurses/ncurses.faq.html ...RSS] ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.aix NNTP-Posting-Host: 60.241.85.208 References: <1184318425.343287.262630@g37g2000prf.googlegroups.com> Message-ID: Date: Sat, 14 Jul 2007 00:17:04 +1000 From: Gary R. Schmidt Subject: Re: Asking for a sample curses library demo / usage in AIX richard wrote: > Hi, > > Anyone knows a sample source code that demonstrates curses library in > AIX (I'm currently using AIX 5L 5.3). In brief, I just wanted to > display a text (echoing) using a color (e.g.: blue, green, etc.). > Please, I couldn't find it by search engine. > > Thanks In Advance, Here you go - should work on AIX, it's about 15 years old, and it still works on Solaris. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . #include main() { int i, x, y, c; short f, b; initscr(); if (start_color() != OK) { mvaddstr(20, 0, "I don't have color!!!"); refresh(); goto endit; } noecho(); nonl(); cbreak(); /* !! */ clear(); erase(); for (c = 0, x = 0; x < 8; x++) for (y = 0; y < 8; y++) { init_pair((short)c, (short)x, (short)y); ++c; } mvaddstr (2, 1, "All the colours of the rainbow..."); move (4, 0); for (c = 1; c < 128; c++) { attrset (COLOR_PAIR(c)); printw ("% 4d", c); attrset(A_NORMAL); addch (' '); } refresh(); x = y = 1; getch(); endit: endwin(); } ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Path: cs.utk.edu!gatech!swrinde!elroy.jpl.nasa.gov!newncar!hsdndev!admii !smoke!gwyn Message-ID: <20904@smoke.brl.mil> References: Organization: U.S. Army Ballistic Research Lab, APG MD. Date: 14 Jan 1994 14:15:32 GMT From: gwyn@smoke.brl.mil (Doug Gwyn) Subject: Re: Making termcap/terminfo entries advice? In article , jeffo@uiuc.edu (J.B. Nicholson-Owens) writes: > > I've been making termcap entries lately and I've come to the > conclusion that: To get things to work as they should, define as > little as possible and when it comes to defining things that move the > cursor around, define only "cg" (termcap) since everything else can > be derived from that. (I assume you meant "cm".) I disagree with this. The termcap/terminfo entry is supposed to be the most complete feasible description of each terminal model's capabilities, which implies that you should not leave out any capabilities that exactly fit the model(s) assumed by termcap. Judging by another post, you're feeling frustrated by poorly-written programs that don't use this information properly. The correct solution is to hammer on the so-called programmers of such programs until they do things right. - Douglas A. Gwyn, 4.3BSD termcap manual editor ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.admin,comp.unix.misc,comp.unix.programmer, comp.unix.questions,comp.unix.solaris,comp.unix.sys5.misc, comp.unix.user-friendly,alt.lang.teco Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!nntp-server.caltech.edu !netline-fddi.jpl.nasa.gov!elroy.jpl.nasa.gov!swrinde !howland.reston.ans.net!agate!darkstar.UCSC.EDU!news.hal.COM!halsoft.com !netcomsv!triada!mgg In-Reply-To: davis@pacific.mps.ohio-state.edu's message of Tue, 9 Aug 1994 19:51:37 GMT Message-ID: Reply-To: mgg@iceman.triad.com References: <1994Aug9.195137.21625@pacific.mps.ohio-state.edu> X-Phone: +1 510 449 0606 x6513 Organization: Triad Systems, Livermore CA Date: Wed, 10 Aug 1994 23:36:25 GMT From: mgg@iceman.triad.com (Mark Galbraith) Subject: Re: Alternate editor to VI >>>>> On Tue, 9 Aug 1994 19:51:37 GMT, >>>>> davis >>>>> from the organization of The Ohio State University; Department of Phyiscs >>>>> who can be reached at: davis@pacific.mps.ohio-state.edu >>>>> (whose comments are cited below with " davis> "), >>>>> said this in article <1994Aug9.195137.21625@pacific.mps.ohio-state.edu> >>>>> concerning the subject of RE: Alternate editor to VI davis> I agree with you that one should support TERMCAP. Whether you support TERMCAP or TERMINFO is really a decision to be made while looking at the platforms you are going to end up on. If you are going to be on some form of System V, you should be supporting TERMINFO. For BSD, the choice would be TERMCAP. Perhaps a better solution would be for your code to check to see if TERMINFO is available. If so, use it, if not fallback to TERMCAP. This way, you can work with the more complete database capabilities of TERMINFO, without completely sacrificing your compatibility with system which only have TERMCAP. davis> At least entries in the termcap database are readable. davis> Terminfo entries are very cryptic. No more so than termcap. True, you must use a program to extract the information from the compiled TERMINFO file, but that compiled file also means that it parses into the system faster. Once decompiled into their plain-text form, they are just about the same as termcap entries. davis> However, given the fact that a terminfo terminal definition is davis> basically a stack-based mini-language, more terminals can be davis> supported. Are there really any terminals manufactured today davis> that require a terminfo definition? None that I am aware of, but then we support a combination of terminfo/termcap applications (and some that have their own extended terminal databases) in our released software. This means that we must maintain two (actually six) different files when a new terminal is added to the supported list. So much for standards. ;-) -- Mark Galbraith Voice: +1 510 449 0606 x6513 Senior Software Engineer/Postmaster FAX: +1 510 373 9611 Triad Systems Corporation E-mail: mgg@triad.com Livermore, California "#include " [Archiver's Note: the trend since the above posting has been towards terminfo.] ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals,comp.lang.perl Path: cs.utk.edu!darwin.sura.net!rsg1.er.usgs.gov!jobone!newsxfer.itd.umich.edu !newsrelay.iastate.edu!news.iastate.edu!cfrandal Organization: Iowa State University, Ames, Iowa (USA) Message-ID: <32bav0$hta@news.iastate.edu> References: NNTP-Posting-Host: wingtip.cc.iastate.edu Date: 10 Aug 1994 19:48:48 GMT From: cfrandal@iastate.edu (Charles F Randall) Subject: Re: [Q] program to parse termcap file? Bill Burton wrote: > >Does anyone know of a program to extract and possibly compare termcap >entries? Something along the lines of infocmp would be nice. Bill, Look in the Perl library (in /usr/local/lib/perl on my system) for 'termcap.pl'. It's documented on Page 409 of my copy of the Camel book. To use it, simply add this line to the top of your program: require 'termcap.pl'; termcap.pl loads the termcap into the associative array %TC. For comparisons, review the sections "Computing the difference/intersection of two arrays" (pg 206-207 in my Camel book). You should be able to hack up something similar from those examples. (even though they're normal arrays) -Randy Charles F. Randall, IV e-mail: cfrandal@iastate.edu Systems Analyst voice : (515) 294-9316 Computation Center office: 113 Durham Iowa State University ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals,comp.unix.programmer,comp.os.linux.misc Path: cs.utk.edu!gatech!howland.reston.ans.net!math.ohio-state.edu!usenet From: davis@pacific.mps.ohio-state.edu Subject: Line Drawing Characters Date: 16 Oct 1994 03:02:27 GMT Organization: None Lines: 51 Message-ID: <37q543$8ru@mathserv.mps.ohio-state.edu> Reply-To: davis@amy.tch.harvard.edu NNTP-Posting-Host: pacific.mps.ohio-state.edu Hi, After reading the man pages for termcap and terminfo as well as the termcap/terminfo book, I have come to the conclusion that termcap/terminfo has very little to say about line drawing characters and alternate character sets. It is my understanding that there are basically four termcap strings that must be considered: ac str graphic character set pairs aAbBcC - def=VT100 ae str (P) end alternate character set as str (P) start alternate character set and another to initialize the alternate character set. Now, I understand each of these strings but I do not understand the relationship between the `ac' and the `ae/as' strings. If `ac' is given, then are the line drawing characters supposed to be in the alternate character set? What if `ac' is not given? Then do I assume that the terminal uses VT100 line drawing sequences? For the vt100, I have to switch to the appropriate alternative character set and then output `l', `m', etc... to get line drawing characters. For systems with the `ac' string defined, I output the charactor paired to `l', etc... Unfortunately, this does not work on all systems because some alternative character sets do not include the line drawing characters. Summary of my questions: 1. If `ac' is not given, do I assume that there is no line drawing characters, or, as is suggested in the man page, do I assume VT100 style line drawing? 2. If `ac' is given, do I assume that the line drawing characters are in the alternate character set? This seems to be one of those little understood gray areas--- at least this is suggested by the lack of any clear documentation. I do not understand why it was not simply implemented as a boolean flag: either the terminal supports line drawing characters or not. If it does, do XXX to begin using these characters and do YYY to end the mode. Thanks. -- _____________ #___/John E. Davis\_________________________________________________________ # # internet: davis@amy.tch.harvard.edu # bitnet: davis@ohstpy # office: 617-735-6746 # ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals,comp.unix.programmer,comp.os.linux.misc Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!uwm.edu!news.alpha.net !news.mathworks.com!uhog.mit.edu!europa.eng.gtefsd.com !howland.reston.ans.net!pipex!uunet!peach!root From: rcs@america.net (Richard C. Schmidt) Subject: Re: Line Drawing Characters Date: 18 Oct 1994 16:53:25 GMT Organization: Access America(TM), P.O. Box 1222, Alpharetta, GA 30239-1222 Message-ID: <380ui5$kvg@peach.america.net> References: <37q543$8ru@mathserv.mps.ohio-state.edu> NNTP-Posting-Host: 199.170.121.125 In article <37q543$8ru@mathserv.mps.ohio-state.edu>, davis@pacific.mps.ohio-state.edu says: > > >Hi, > > After reading the man pages for termcap and terminfo as well as the > termcap/terminfo book, I have come to the conclusion that termcap/terminfo > has very little to say about line drawing characters and alternate character > sets. It is my understanding that there are basically four termcap strings > that must be considered: Actually, the easiest way to do this is to use the tput command. When combined with terminfo/termcap, it makes a large numnber of screen handlers available to the shell environment. You also have the benefit of it being terminal independant. By this, I mean, if the terminal will support it, and the terminfo/termcap entry is correct, it doesn't matter what terminal you are using, it will work. If you are using 'C' to write an application, try considering 'curses'. Richard Schmidt ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals,comp.unix.programmer,comp.os.linux.misc Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!mp.cs.niu.edu !vixen.cso.uiuc.edu!howland.reston.ans.net!math.ohio-state.edu!usenet From: davis@pacific.mps.ohio-state.edu Subject: Re: Line Drawing Characters Date: 18 Oct 1994 17:50:24 GMT Message-ID: <3811t0$910@mathserv.mps.ohio-state.edu> References: <37q543$8ru@mathserv.mps.ohio-state.edu> <380ui5$kvg@peach.america.net> In article <380ui5$kvg@peach.america.net>, rcs@america.net (Richard C. Schmidt) writes: : >sets. It is my understanding that there are basically four termcap strings : >that must be considered: : Unfortunately, you omitted the relevant part of my post. : Actually, the easiest way to do this is to use the tput command. : When combined with terminfo/termcap, it makes a large numnber : of screen handlers available to the shell environment. You also : have the benefit of it being terminal independant. By this, I mean, : if the terminal will support it, and the terminfo/termcap entry is : correct, it doesn't matter what terminal you are using, it will work. : : If you are using 'C' to write an application, try considering 'curses'. It is not this simple as I was trying to point out. From what I can tell, curses and ncurses do the logical thing: assume that the line drawing characters are in the alternate character set. This assumption is simply not valid. As a result, `curses' is not the solution. A better thought out termcap/terminfo is the solution. I tried to point this out in my previous article. -- _____________ #___/John E. Davis\_________________________________________________________ # # internet: davis@amy.tch.harvard.edu # bitnet: davis@ohstpy # office: 617-735-6746 # ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals,comp.unix.programmer,comp.os.linux.misc Path: cs.utk.edu!stc06.CTD.ORNL.GOV!rsg1.er.usgs.gov!jobone !newsxfer.itd.umich.edu!europa.eng.gtefsd.com!howland.reston.ans.net !EU.net!sun4nl!cwi.nl!news.cwi.nl!aeb From: aeb@cwi.nl (Andries Brouwer) Subject: Re: Line Drawing Characters Message-ID: Sender: news@cwi.nl (The Daily Dross) Nntp-Posting-Host: zeus.cwi.nl References: <37q543$8ru@mathserv.mps.ohio-state.edu> Date: Tue, 18 Oct 1994 23:20:56 GMT davis@pacific.mps.ohio-state.edu writes: : : ac str graphic character set pairs aAbBcC - : def=VT100 : ae str (P) end alternate character set : as str (P) start alternate character set : and another to initialize the alternate character set. ... : Summary of my questions: : 1. If `ac' is not given, do I assume that there is no line drawing : characters, or, as is suggested in the man page, do I assume VT100 : style line drawing? : : 2. If `ac' is given, do I assume that the line drawing characters are in : the alternate character set? : : This seems to be one of those little understood gray areas--- at least this : is suggested by the lack of any clear documentation. I do not understand : why it was not simply implemented as a boolean flag: either the terminal : supports line drawing characters or not. If it does, do XXX to begin using : these characters and do YYY to end the mode. My understanding is the following: 1. The alternate character set need not contain line drawing characters; this set might just as well have Greek or Hebrew characters. So: as, ae are meaningful apart from line-drawing questions. 2. If `ac' is not given, then no conclusion about the availability of line drawing characters can be drawn. 3. If `ac' is given then, yes, you may assume that you have to use eA, as to start line drawing, and ae to end it. Very few programs use these strings. (But maybe you are writing one yourself?) Note that *the* alternate character set may not be well-defined. ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals,comp.unix.programmer,comp.os.linux.misc Path: cs.utk.edu!gatech!usenet.ins.cwru.edu!wariat.org!kf8nh!bsa From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Message-ID: <1994Oct19.023814.7864@kf8nh.wariat.org> Organization: Brandon's Linux box and AmPR node, Mentor, OH Date: Wed, 19 Oct 1994 02:38:14 GMT References: <37q543$8ru@mathserv.mps.ohio-state.edu> Subject: Re: Line Drawing Characters Lines: 66 In article , aeb@cwi.nl (Andries Brouwer) says: +--------------- | davis@pacific.mps.ohio-state.edu writes: | : ac str graphic character set pairs aAbBcC - | : def=VT100 | : ae str (P) end alternate character set | : as str (P) start alternate character set | | : 1. If `ac' is not given, do I assume that there is no line drawing | : 2. If `ac' is given, do I assume that the line drawing characters are in | : the alternate character set? | 1. The alternate character set need not contain line drawing characters; | this set might just as well have Greek or Hebrew characters. | So: as, ae are meaningful apart from line-drawing questions. | 2. If `ac' is not given, then no conclusion about the availability | of line drawing characters can be drawn. | 3. If `ac' is given then, yes, you may assume that you have to use eA, as | to start line drawing, and ae to end it. +------------->8 You're probably better off reading the System V curses (or ncurses) terminfo manpage and reading "smacs" as "as", "rmacs" as "ae", "enacs" as "eA", and "acs" as "ac". If "ac" is not defined, it defaults (in System V curses, at least) to a mapping from VT100 line graphics to a low-quality ASCII simulation using + - | characters. If it is empty (":ac=:") then it is the null mapping, that is, VT100 characters are used for line drawing. Otherwise, it is a mapping from VT100 characters to the terminal's line-drawing characters: first the VT100 character, then the terminal's line-drawing character. When a program is going to use line-drawing characters, it should output the "eA" string, if defined, during terminal initialization (that is, at the same time as it outputs "ti"). To use line-drawing characters, it should output "as" if defined, then the line-drawing characters as mapped by "ac", then "ae" if defined. Note that it is valid for "as"/"ae" to be undefined; consider a PC-ANSI emulation using 8-bit characters for graphics, as is common on BBSes. "ac" would map VT100 characters to 8-biut characters and "as" and "ae" would be either undefined or empty. The purpose of "eA" is to allow for terminals which use both national and line-drawing character sets; on a VT100, one could define line-drawing with :as=\E(0:ae=\E(B:ac=: but this assumes that the text character set should be U.S. ASCII. (On the VT100, "\E(B" selects U.S. ASCII, while "\E(A" selects a U.K. variant. "\E(0" selects the line-drawing character set. Later VTx00 terminals also define other national character sets.) Instead of doing this, the VT100's GL/GR feature is used: :eA=\E)0:as=^N:ae=^O:ac=: which loads the line-drawing set into GR, leaving the user's chosen character set in GL (the default character set), then toggles between GL for text and GR for graphics. (Later models have G2 and G3 character sets as well, allowing switching between up to four character sets.) Another advantage of this on a VT100 is that the sequence for switching character sets is faster, but this is incidental to the main point of not screwing up the user's preferred text character set. ++Brandon -- Brandon S. Allbery KF8NH [44.70.4.88] bsa@kf8nh.wariat.org Linux development: iBCS2, JNOS, MH ~\U Waiting For Godot^H^H^H^H^HRothenberg ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.sys.dec,comp.unix.misc,comp.terminals,comp.os.linux.misc Path: stc06.ctd.ornl.gov!fnnews.fnal.gov!uwm.edu!math.ohio-state.edu !jussieu.fr!oleane!hole.news.pipex.net!pipex!tube.news.pipex.net!pipex !plug.news.pipex.net!pipex!tank.news.pipex.net!pipex!news.mathworks.com !uunet!in1.uu.net!yrkpa.kias.com!butterfly.hjs.com!butterfly.hjs.com From: root@butterfly.hjs.com (John Flinchbaugh) Date: 18 May 1996 03:20:47 -0400 Organization: Happy John Software Message-ID: <4njtof$4dl@butterfly.hjs.com> References: <4n9ukr$ijn@hiekkalaatikko.cs.hut.fi> Reply-To: glynis@yrkpa.kias.com Subject: Re: vt100 escape codes Joonas Timo Taavetti Kekoni (jkekoni@cc.hut.fi) wrote: > ARE vt100 or newer vt codes publicly available anywhere? > How do i turn vt100 to "graphic" character mode. > > Can i use ncurses to output graphic characters to STANDARD OUTPUT. I've seen programs using ncurses use the extended IBM graphic characters, but it only worked well if the terminal supported the IBM graphic character set, otherwise it the terminal just substituted in whatever it had in that characters place. generally, if your terminals can't be set for the needed character set, then just use what is most common, or stick to 7-bit characters (ascii 0-127). ncurses does reference the termcap, so it can adjust its escape codes for whatever kind of terminal you are using, as long as it's in the termcap. (ps--if anyone finds this information misleading, please correct me as soon as you can. i do not want to be spreading any misinformation. thanks.) -- _____________________}John Flinchbaugh{_______________________ | -> glynis@yrkpa.kias.com <- http://yrkpa.kias.com/~glynis | | jmflinch@cs.millersv.edu jmf89784@marauder.millersv.edu | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.databases.pick,comp.os.ms-windows.apps.comm,comp.terminals Path: cs.utk.edu!gatech!swrinde!pipex!uunet!psinntp!psinntp!news From: BenR@Unidata.Com (Ben Rosenberg) Subject: Re: Wyse50 emulation over winsock Message-ID: <1994Dec4.000219.4642@nntpxfer.psi.com> Sender: news@nntpxfer.psi.com Organization: Unidata, Inc., Denver, Colorado, U.S.A. References: <3bnd04$9pj@news1.deltanet.com> <3bndgd$9pj@news1.deltanet.com> Date: Sun, 4 Dec 1994 00:02:19 GMT Lines: 76 In article <3bnd04$9pj@news1.deltanet.com> and article <3bndgd$9pj@news1.deltanet.com>, john@delta1.deltanet.com (John Lombardo) asked: > Organization: Delta Internet Services, Anaheim, CA > Newsgroups: comp.databases.pick,comp.terminals > Date: 2 Dec 1994 > Subject: Wyse50 emulation over winsock > > Does anyone know of a complete wyse50 terminal emulator > that will run over winsock? > I already know about Procomm Plus for windows, > but they don't run over winsock. > Wintegrate works over winsock, but their wy50 > emulation is not good enough for my customer. > Crosstalk for windows falls into the same category as > Wintegrate -- incomplete emulation. > Any suggestions? > What would the demand be for a programmable > terminal emulator that came with many emulations, > and priced for, say $50-$75 per client cpu? > One could easly be done in C++ using termcap files as > input for the terminal emulation. Anyone want to write one? Unix termcap and terminfo files are far less complete and less correct than many folks would hope and imagine, so you'll need to write that, as well as your "easily done" (?) C++. I've not yet seen a version of Unix that shipped from the o/s vendor with correct and complete terminfo or termcap, even for basic keyboard input and display output codes, never mind more advanced features such as programming fkeys, fkey labels, 25th Line, 26th Line, etc. Unidata's "wIntegrate" software is written in C++ and includes a facility which is something like Unix termcap. The "*.WIT" files are ASCII text files which control the terminal emulations. End users can modify existing emulations and/or create new emulations. Recently I created E_WY50.WIT and U_WY50.WIT files to handle some of the quirks of Wyse's so-called "enhanced" and "unenhanced" modes. It was nice that I didn't need to get a patch from the wIntegrate software engineers. The only tool I needed was Windows notepad, to modify the original WYSE50.WIT file. It was no harder than dealing with Unix termcap or terminfo. Disclaimer: Unidata, Inc., are my employer. *** Another path is to find a terminal emulator you like that doesn't support WinSock directly, (such as PROCOMM) and fool it (that is, connect "COMx:" to Winsock Telnet). I've misplaced my note on COMx-to-Winsock redirection software but I can dig up that note if anybody's interested. *** cheers, Ben -- Ben Rosenberg * Unidata Tech Support * Trenton, New Jersey, U.S.A. * BenR@Unidata.Com ////////////////////////////////////////////////////////////////////////////// Date: Thu, 27 Aug 1998 11:01:03 -0400 (EDT) To: Rohit From: "Richard S. Shuford" Subject: Re: Doubt regarding terminal capabilities. In-Reply-To: <3.0.2.32.19980827132058.00e39ee8@bombay> Message-ID: Sir Rohit: >Date: Thu, 27 Aug 1998 13:20:58 +0500 >From: Rohit >Subject: Doubt regarding terminal capabilities. > >I have here an excerpt from a termcap file. This excerpt shows the terminal >capabilities for just the vt100 terminal. This mentions that the sequence >of characters to be sent to a vt100 terminal for clearing the entire screen >and >putting the cursor at upper left corner -- cl -- is 50\E[;H\E[2J. I do not >understand how a command sequence can begin with a number, 50 in this case. >I thought that commands *always* begin with ESC. What have I not understood? > >d0|vt100|vt100-am|vt100am|dec vt100:\ > :do=^J:co#80:li#24:cl=50\E[;H\E[2J:sf=5\ED:\ > :le=^H:bs:am:cm=5\E[%i%d;%dH:nd=2\E[C:up=2\E[A:\ > :ce=3\E[K:cd=50\E[J:so=2\E[7m:se=2\E[m:us=2\E[4m:ue=2\E[m:\ > :md=2\E[1m:mr=2\E[7m:mb=2\E[5m:me=2\E[m:is=\E[1;24r\E[24;1H:\ > :rf=/usr/share/lib/tabset/vt100:\ > :rs=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h:ks=\E[?1h\E=:ke=\E[?1l\E>:\ > :ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:kb=^H:\ > :ho=\E[H:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:pt:sr=5\EM:vt#3:xn:\ > :sc=\E7:rc=\E8:cs=\E[%i%d;%dr: > >It is the same for some other capabilities also. >Please get back to me on this. >Thanks >Rohit > >Rohit (rohitm@informix.com) >Informix Software India Private Limited, I'm not really an expert on termcap or terminfo; what I know comes mostly out of the book "termcap and terminfo" by Strang, Mui, and O'Reilly (published by O'Reilly and Associates, ISBN 0-937175-22-6, Order Number 226; 270 pages, $21.95 US). See http://www.ora.com/catalog/term/ [2004 update: price is now $29.95] The '5' and '0 are not characters to be literally transmitted to the terminal. The digits are intended to be used internally by the host program (under control of "curses", "ncurses", or equivalent). On page 34 of the O'Reilly book we find the following paragraph: Padding Syntax in termcap termcap indicates padding by specifying the delay time in milliseconds after the equal sign and before the command code in a string capability. For example, ho=10^^ would indicate a delay of 10 milliseconds after the cursor is moved to the "home" position with the ^^ (Control-caret) command. -- ...Richard S. Shuford | "It is not good to have zeal without knowledge, ...shuford%cs.utk.edu | nor to be hasty and miss the way." ...................... | Proverbs 19:2 ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.editors,comp.terminals Path: cs.utk.edu!nntp.memphis.edu!nntp.msstate.edu!gatech !howland.reston.ans.net!swiss.ans.net!news.dfn.de!Germany.EU.net !EU.net!sun4nl!news.nic.surfnet.nl!tuegate.tue.nl!news.win.tue.nl !news.win.tue.nl!not-for-mail Subject: Re: vi macro problem Message-ID: <3a8504$afa@wsinti05.win.tue.nl> From: hansm@wsinti05.win.tue.nl (Hans Mulder) Date: 14 Nov 1994 17:58:44 +0100 Reply-To: hansm@win.tue.nl References: Distribution: inet Organization: Eindhoven University of Technology, The Netherlands NNTP-Posting-Host: wsinti05.info.win.tue.nl Lines: 30 In jzero@netcom.com (Jim Nakamura) writes: > By the way, I've been using vi (version SVR3.1). Does > anyone know offhand whether this uses termcap or > terminfo? Terminfo. > I've tried fixing my problem this way, but > no luck. Even though I've assigned a dummy file name > to $TERM and point it to the file in my directory > $TERMCAP, vi insists it doesn't know anything about it > and opens up in "open" mode (even after I've assigned > a term=dummy variable in my .exrc file). Setting TERMCAP has no effect if you use a terminfo-based vi. > With my > terminfo, whenever I try to compile it with tic, it > fails because it attempts to store the compiled information > in /usr/share/lib/terminfo which of course is write > protected. :( The trick is to set the TERMINFO environment variable before you try to run tic. -- Hope this helps, HansM ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!uwm.edu!vixen.cso.uiuc.edu !uxh.cso.uiuc.edu!dawn From: dawn@uxh.cso.uiuc.edu (Dawn Owens-Nicholson) Subject: Re: TeleVideo TVI925 TermCap Date: 18 Feb 1995 08:17:43 GMT Organization: University of Illinois at Urbana Message-ID: <3i4af7$gdl@vixen.cso.uiuc.edu> References: <3hqgqe$4np@cronkite.ocis.temple.edu> <3htg33$9re@ionews.io.org> tla@io.org (Steve Thompson) writes: > >The problem with pico and pine (and other things) is that the control >codes are considered by the termcap file to "take up space" in video >memeory, I believe. Anyways, I see a leading space after highlighting >has started (underline too). This causes some things to scroll over to >the next line when they shouldn't. The problem is probably one of two things: (1) The terminal description you're using is buggy. In your termcap or terminfo term definition the 'magic cookies' are undefined. The magic cookie is a number of characters needed to turn on or off an effect (such as underlining or inverse video). As you said, in your case, the magic cookie is 1 character. The problem is similar for termcap and terminfo users, so I'll cover both. Termcap users should define "sg#" (e.g., "sg#1" for a 1 character magic cookie) and terminfo users should define "xmc#" (e.g., "xmc#1"). If your terminal enters and leaves effect modes (underline, inverse, etc.) without spaces, there is no need to define sg# or xmc# at all (in fact defining this in a termcap entry takes up valuable space). NOTE: sg#/xmc# are termcap/terminfo for standout mode. For underlines, the magic cookie capability is ug# (termcap only). Terminfo's magic cookie capability is xmc# as well. If underlining and standout modes need differing numbers of magic cookies, pad the shorter one with spaces when you define how to turn on and off that mode. So, if standout needs 2 spaces, but underlining only needs 1, define 'underline on' and 'underline off' (us= & ue= in termcap; smul= and rmul= in terminfo) to be: (termcap) (terminfo) us= smul=\s ue= rmul=\s ug#2 xmc#2 sg#1 Notice how in the termcap code Notice how in the terminfo description, real spaces are used. "\s" means the space character. In both definition examples "" should be replaced (the angle brackets too). (2) The apps you're using are buggy. A lot of apps written for use on character terminals were tested only on VT-100s or their ilk and far too many programs don't grasp the finer points of termcap/terminfo library definitions. I've submitted more bug reports to more developers than I care to count, but in their defense it's difficult work designing a program to work on all terminals with properly written termcap/terminfo entries. Termcap is harder to work with since it's so much less capable of accurately describing all the subtleties in such short a space. >Additionally, the cursor keys are undefined. (termcap) (terminfo) kl= left arrow key kcuu1= kr= right arrow key kcuf1= ku= up arrow key kcub1= kd= down arrow key kcud1= kh= home key (if present) khome= >I did download some termcap entries for tvi9xx that reside in cs.utk.edu >(I think) and in the directory /pub/[name]/terminal. I can't remember >[name] but it begins with 's'. :) Richard S. Shuford's archive is extremely useful: http:/www.cs.utk.edu/~shuford/terminal_index.html Also you should pick up a copy of "termcap & terminfo" from O'Reilly Books. The combination of the two make up the answer to virtually every question posed to this group. -Dawn ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Path: cs.utk.edu!nntp.memphis.edu!nntp.msstate.edu!emory !news-feed-1.peachnet.edu!usenet.eel.ufl.edu!news.mathworks.com !transfer.stratus.com!xylogics.com!Xylogics.COM!carlson Message-ID: <3iv3e8$gt4@newhub.xylogics.com> Date: 28 Feb 1995 12:03:20 GMT References: Organization: Xylogics Incorporated From: carlson@Xylogics.COM (James Carlson) Subject: Re: vt100 Question In article , malek@tor.hookup.net (Malek Abdel-Fattah) writes: |> |> Here's another question about terminal definitions (not just vt100). |> |> When termcap contains a string such as \E[?7h, such as in the example: |> |> te=150\E?7h |> |> Is the '?' literal (ie, is it sent to the terminal) or is it a denoter |> such as %d and %i and so on. It would be nice to find a listing of terminal It's a literal, and is sent to the terminal. The "150" in front, though, is not a literal, and specifies a 150 millisecond delay after sending the command. Do a "man 5 termcap" for more information on the file format, or run to the bookstore. There are an awful lot of different capability codes on different systems. --- James Carlson Tel: +1 617 272 8140 Annex Software Support / Xylogics, Inc. +1 800 225 3317 53 Third Avenue / Burlington MA 01803-4491 Fax: +1 617 272 2618 ////////////////////////////////////////////////////////////////////////////// Path: cs.utk.edu!nntp.memphis.edu!nntp.msstate.edu!gatech !howland.reston.ans.net!vixen.cso.uiuc.edu!uwm.edu!news.alpha.net !news.mathworks.com!transfer.stratus.com!xylogics.com!Xylogics.COM!carlson Newsgroups: comp.terminals Subject: Re: Termcap Info Message-ID: <3iv3i2$gt4@newhub.xylogics.com> From: carlson@Xylogics.COM (James Carlson) Date: 28 Feb 1995 12:05:22 GMT References: In article , malek@tor.hookup.net (Malek Abdel-Fattah) writes: |> |> Hi there, |> Lately I have spent much of my time researching terminal types |> for a development project I am currently involved in. Unfortunately, I am |> working on a old Xenix 286 operating system. My problem comes when |> referencing the manual to find out the meanings of different terminal |> capabilities. I'll use 'vt100' as my example here. For the vt100 terminal |> type, I was unable to find descriptions for the following capabilities: |> |> bl, ct, DO, it, LE, le, mb, md, me, nw, rc, RI, rs, sc, st, vt, |> and xo. |> |> Is there somewhere I can find a complete listing of capability |> definitions? I would appreciate any help. Yes. Read the man page -- termcap(5). Here are a couple of those: bl str (P) audible signal (bell) ct str (P) clear all tab stops DO str (NP*) move cursor down n lines it num tab stops initially every n positions The rest are in the documentation. --- James Carlson Tel: +1 617 272 8140 Annex Software Support / Xylogics, Inc. +1 800 225 3317 53 Third Avenue / Burlington MA 01803-4491 Fax: +1 617 272 2618 ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals,alt.folklore.computers Path: cs.utk.edu!nntp.memphis.edu!nntp.msstate.edu!gatech !howland.reston.ans.net!vixen.cso.uiuc.edu!uxh.cso.uiuc.edu!dawn Message-ID: <3j0h5d$2km@vixen.cso.uiuc.edu> Date: 1 Mar 1995 01:03:41 GMT References: <3iifuu$dan@netaxs.com> <3impu5$hlp@vixen.cso.uiuc.edu> <3j02j3$ho8@holly.csv.warwick.ac.uk> Organization: University of Illinois at Urbana NNTP-Posting-Host: uxh.cso.uiuc.edu From: dawn@uxh.cso.uiuc.edu (Dawn Owens-Nicholson) Subject: Re: Questions about archaic terminals xuuah@csv.warwick.ac.uk (Daniel Barlow) writes: >Looking at the web page that Eric quoted >(http://www.ccil.org/~esr/ncurses.html for anyone who missed it)o > [ as of 2004, the above URL is stale; try > http://catb.org/%7Eesr/terminfo/index.html ] Thanks for the info. > It looks like BSD will go to ncurses (and hence terminfo) as soon as > Keith Bostic (nvi maintainer) decides that it's stable and works with > nvi. I was hoping that they wouldn't go to terminfo. [...] I think the move to terminfo is a big plus (in the long run) for everyone involved. I find the length and padding limits in termcap extremely annoying (in fact the length limit makes some of my own entries incomplete). I do like the all-plaintext approach of termcap (no need for compiling anything--just type it in and test it out), but that's about the only thing I can say in termcap's favor. I'm not sure what you mean by your 'average user' problem; I believe under both termcap and terminfo if the terminal isn't listed in the database, there won't be any full-screen control. I don't believe this has anything to do with the technology in terminfo or termcap per se, as this is akin to a "file not found" error. >The colour support would be (is) good though. As are the finer control over padding, unlimited length entries (which really helps for building inheritance trees of entries) and other stuff too long to get into here. -Dawn ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Path: cs.utk.edu!stc06.ctd.ornl.gov!fnnews.fnal.gov!uwm.edu!vixen.cso.uiuc.edu !uxh.cso.uiuc.edu!dawn Organization: University of Illinois at Urbana Message-ID: <3lif8f$sm0@vixen.cso.uiuc.edu> References: <3lel1a$68o@gandalf.rutgers.edu> <3li3vd$dub@griffin.itc.gu.edu.au> Date: 1 Apr 1995 02:54:07 GMT From: dawn@uxh.cso.uiuc.edu (Dawn Owens-Nicholson) Subject: Re: Help with termcap Tony Nugent writes: > > man terminfo is what you want to read. But it's a huge file and > having to lookup everything is *such* a tedious task!!! Another reason why I recommend the "termcap & terminfo" book from O'Reilly. You can start on the first page of capability descriptions and just enter what you need as you go through the rest of the pages. It's really nice that way. It could use a better index though. > You can convert a termcap into terminfo with infocmp, but how you > you do the reverse??? Ok, tic compiles a terminfo.src file into > the binaries, but I'm looking for an easy way to convert the > output of infocmp into a format for termcap. See, if you had "termcap & terminfo" you'd know that "infocmp" from the AT&T Toolchest also converts from terminfo to termcap. Of course, any automated conversions can't produce equivalent entries in all cases, and all output should be hand-checked and tested. Try "infocmp -C " for converting the installed terminfo entry to termcap and writing it on stdout. Moral of the story: Everyone considering doing *anything* with either termcap or terminfo should buy this book. This book should be mandatory reading for comp.terminals readers. -Dawn ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals,comp.sys.hp.hpux Path: cs.utk.edu!cssun.mathcs.emory.edu!emory!swrinde!sdd.hp.com!hplabs !hplextra!news.dtc.hp.com!col.hp.com!fc.hp.com!agosta Followup-To: comp.terminals,comp.sys.hp.hpux Organization: Hewlett-Packard Fort Collins Site Message-ID: <3mu0l7$obe@tadpole.fc.hp.com> References: <1995Apr7.152134.25551@ka4ybr.com> Date: 17 Apr 1995 15:14:47 GMT From: agosta@fc.hp.com (John Agosta) Subject: Re: termcap entry Sue Gutkes KE4HNN (sbg@ka4ybr.com) wrote: : I am currently looking for a termcap entry for SunOS for 'hpterm'. : If anyone can help, please email the entry to me at : sgutkes@ntera.com. Terminfo files work across Sun and HP systems. Therefore, you can take the "hpterm" file from your HP system under /usr/lib/terminfo/h/hpterm and copy it to the Sun system. Now, I haven't figured out when SunOS systems think they need to use a terminfo vs. a termcap definition (I think it has something to due with the phases of the moon), but this solution is not complete for some SunOS commands; like "clear". Therefore, you also need to put an "hpterm" entry in your /etc/termcap file on the SunOS. Just add the word "hpterm" to your "hp" termcap entry. Hope that helps, -- John Agosta agosta@fc.hp.com ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals,comp.sys.hp.hpux Path: cs.utk.edu!cssun.mathcs.emory.edu!emory!gatech!bloom-beacon.mit.edu !senator-bedfellow.mit.edu!usenet From: davis@space.mit.edu Subject: Re: termcap entry Date: 8 May 1995 13:27:35 GMT Organization: Center for Space Research Message-ID: <3ol687$2rq@senator-bedfellow.MIT.EDU> References: <1995Apr7.152134.25551@ka4ybr.com> <3mu0l7$obe@tadpole.fc.hp.com> <3mv3rv$mj4@vixen.cso.uiuc.edu> <3oarad$3p3@senator-bedfellow.MIT.EDU> <3ol2m5$643@hpuamsa.neth.hp.com> Reply-To: davis@space.mit.edu NNTP-Posting-Host: wiwaxia.mit.edu In article <3ol2m5$643@hpuamsa.neth.hp.com>, franks@neth.hp.com (Frank Slootweg) writes: : davis@space.mit.edu wrote: : > Actually, terminfo compiled files are supposed to be portable across any : > system. So, `untic-ing' it is unnecessary--- just copy the fole to the : > other system. : : Are you sure? As far as I know, compiled terminfo files contain : multi-byte binary data. I doubt that that binary data is bi-endian (i.e. : big versus little endian) safe, but could of course be wrong. I am pretty sure about it. I wrote my own terminfo reader for my JED editor and it runs fine on all kinds of Unix systems. Nowhere in the code do I check to see what byte ordering of the machine uses. I wrote it straight from the manpage. In fact, I have included all relevant parts of the man page as comments in the source file. If you want to look at the source, pick up slang.tar.gz from space.mit.edu:/pub/slang. Then look at the file slang/src/sltermin.c. --John ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.arch.embedded,comp.terminals Path: cs.utk.edu!nntp.memphis.edu!nntp.msstate.edu!emory!swrinde !howland.reston.ans.net!nntp.crl.com!pacbell.com!amdahl.com!amd!step!dan Message-ID: Followup-To: comp.terminals References: <7JUN199512355584@erich.triumf.ca> Organization: Step Engineering Keywords: VT-100 Lines: 18 Date: Sat, 10 Jun 1995 17:55:49 GMT From: dan@stepeng.com (Daniel Weaver) Subject: Re: VT-100 Commands In article <7JUN199512355584@erich.triumf.ca>, bennett@erich.triumf.ca (P.Bennett) writes: > > void gotoxy( int x, int y ) > { > printf( "\033[%d;%dH\000\000", y, x ); > } > > /* \033 = Escape */ > > the \000 chars seem to be needed to give the terminal time to do > its thing... I've got some bad news for you, Peter. The \000 character gets swallowed by printf() and never makes it to the terminal. If you want to send NULLs to the terminal, you need to use putc(), or write(). Another way to do this is to send \200 (0x80 hex). printf() stops parsing when it sees the first NULL. Follow-ups should be redirected to comp.terminals. Dan Weaver ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Path: cs.utk.edu!cssun.mathcs.emory.edu!atglab.bls.com!gatech!swrinde !cs.utexas.edu!not-for-mail From: nygren@tecnet1.jcte.jcs.mil Subject: Tscreen+Tstring: C++ terminal screen class Date: 27 Jun 1995 14:38:29 -0500 Organization: UTexas Mail-to-News Gateway Lines: 8 Sender: nobody@cs.utexas.edu Message-ID: <199506271938.OAA10975@mail.cs.utexas.edu> NNTP-Posting-Host: news.cs.utexas.edu I have posted to alt.sources some C++ classes (Tscreen and Tstring) designed to assist terminal screen display construction when the curses library is unavailable for use. Dan Nygren nygren@tecnet1.jcte.jcs.mil ////////////////////////////////////////////////////////////////////////////// Path: cs.utk.edu!nntp.memphis.edu!nntp.msstate.edu!emory!swrinde!cs.utexas.edu !uwm.edu!lll-winken.llnl.gov!enews.sgi.com!decwrl!pacbell.com!amdahl.com !amd!step!dan Newsgroups: comp.unix.programmer,comp.terminals Message-ID: References: <410m13$qhp@hermes.is.co.za> <411im0$lqo@cs3.brookes.ac.uk> Organization: Step Engineering Lines: 29 Date: Sat, 19 Aug 1995 19:55:02 GMT From: dan@stepeng.com (Daniel Weaver) Subject: Re: Curses & Magic Cookie terminals In article , zmbenhal@netcom.com (Zeyd M. Ben-Halim) writes: > >>But there's got to be a better solution... Hasn't there? > >You might want to try using ncurses. I have no idea if it will work as I don't >have such a terminal. Magic cookie terminals are a pain. They should be illegal. (Along with COBOL). But, alas, they are here and we must make the best of it. Testing and creating a termcap/terminfo for magic cookie terminals is possible even when all you have is a "notmal" terminal. Lets say you have a VT-100 style terminal. You change it to a magic cookie terminal by adding a printing character to all of the caps that start or stop attributes. For example: xmc#1, smso=\E[1;7m@, rmso=@\E[m, Yes, the at signs (@) were intentional. Now you can test curses or your application to see how it will react with a magic cookie terminal. After putting up a screen, you check to see if all the at signes (@) are still present. If not, your application screwed up. I don't advicate changing your VT-100 to a magic cookie terminal but anyone that says they can't test magic cookie terminals is just showing a lack of imagination. ----------------------------------------------------------------------- Dan Weaver Disclamer: I don't make cookies, magic or otherwise. ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Path: cs.utk.edu!nntp.memphis.edu!nntp.msstate.edu!olivea!bug.rahul.net!a2i !infoseek.com!uunet!in1.uu.net!news.sprintlink.net!in2.uu.net !dana.ncd.com!usenet Message-ID: <42ppr4$6gg@dana.ncd.com> References: <41lqvc$21f@dfw.net> Organization: NCD NNTP-Posting-Host: lab10.pcx.ncd.com To: jhs@dfw.net,randolph@netcom.com Date: 8 Sep 1995 16:09:08 GMT From: Randolph Fritz Subject: Re: Well, I see no FAQ, so away I ask... jhs@dfw.net (Justin Scott) wrote: > >Thankya much... This is what I get for trying to do hard coding for >vt100 in shell scripts... :) Gee, if I could only use termcap or >terminfo in a shell script... > On many systems, you can. Look up tput(1); it's part of System V so, depending on your OS, you might have to lookin in /usr/5bin. Randolph ////////////////////////////////////////////////////////////////////////////// Path: cs.utk.edu!gatech!news.mathworks.com!uunet!in2.uu.net!news.sprintlink.net !nwnews.wa.com!news1.halcyon.com!coho!dagon Newsgroups: comp.terminals Organization: Northwest Nexus, Inc. - Professional Internet Services Lines: 35 Message-ID: <44an8h$cag@news1.halcyon.com> References: <44adfb$v70@news.gate.net> Date: 27 Sep 1995 05:25:37 GMT From: dagon@coho.halcyon.com (Mark Rafn) Subject: Re: I GIVE UP: tput: usage: "tput [-Tterm] capname" Tim Schaefer wrote: >To all: > >tput worked great on one system, a DG/UX box where I used the syntax: > >tput cup 10 10 > >to provide absolute cursor addressing to row 10 col 10 on the screen >in a shell script. Cool. But now I'm using an RS6000, and an HP9000 >and they both die using this command, giving me the cryptic message: > >tput: usage: "tput [-Tterm] capname" I don't know that this helps, but here are a few data points. tput cup 10 10 works fine on SunOS 4.1.3 and on SCO Unix and Linux. Does not work on Ultrix (no tput command at all). The 'tput [-Tterm] capname' message (and this may be supported by the man page (try man tput)) indicates to me that DG/UX has an old or broken implementation that doesn't accept additional parameters to tput. what does 'tput clear' do? How about 'tput cup' with no additional parameters? Finally, if you don't mind being vt-100 (and PC-ansi) specific, you can use echo -n "^[[11;11H" or echo "\033[11;11H\c" (note that the ^[ is the first example should actually be an ESCAPE character, which you can insert (in vi) with ctrl-v, ESCAPE. good luck! -- Mark Rafn dagon@halcyon.com http://www.halcyon.com/dagon/ ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Path: cs.utk.edu!gatech!news.cse.psu.edu!news.math.psu.edu!ra.nrl.navy.mil !hookup!usenet.eel.ufl.edu!nntp1.jpl.nasa.gov!netline-fddi.jpl.nasa.gov!usenet Organization: Jet Propulsion Laboratory (NASA) Lines: 28 Distribution: world Message-ID: <4l353q$ic1@netline-fddi.jpl.nasa.gov> References: <4krkl2$r1q@heathers.stdio.com> NNTP-Posting-Host: robotics.jpl.nasa.gov Date: 17 Apr 1996 16:09:29 GMT From: litwin@robotics.jpl.nasa.gov (Todd Litwin) Subject: Re: Termcap last char scroll problem? In article <4krkl2$r1q@heathers.stdio.com>, risner@stdio.com (James Risner) writes: > > I have a problem with a termcap. > When a program draws on the last character of the last line, it forces a > scroll and messes up the screen positioning. > > Does anyone know what could cause this and how to fix it? > > Risner > In termcap parlance this is called "automatic margins." This is a result of a terminal characteristic that automatically adds a carriage-return/line-feed when the end of the line is reached. On most terminals with this feature, this will result in scrolling of the display when it occurs on the last line. When a terminal has this characteristic, it should have "am" in its termcap entry. In such a case a smart program will avoid writing in the last column, or will take appropriate action if it does. In one program that I wrote, a text editor, I avoid the problem by making sure never to write in the last column of the last line. If you don't have source-level control over the program in question, then I would recommend making sure that the "am" capability is present in the appropriate termcap entry, and hoping that the program pays attention. -- Todd Litwin Jet Propulsion Laboratory (818) 354-5028 Todd.E.Litwin@jpl.nasa.gov ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.lang.cobol, comp.terminals, comp.unix.aix, comp.periphs Date: 5 Sep 1996 14:46:07 -0400 From: Richard Shuford Subject: Re: terminfo files for AIX 2.3 In article <322EB2E4.594F@lincsys.com>, Jim Egerton writes: > > Anyone have terminfo files (xterm, vt100, aixterm) that work > with the Microfocus toolbox on AIX? > > Using the files shipped with Microfocus V.3.2.37 I have tried > using an aixterm as well an xterm with TERM set to xterm and > vt100. With the aixterm or xterm and TERM=xterm, the video > didn't work properly (line's were displayed as qqqqqq). The display of a row of "qqqqqqq..." is a symptom of the client application wanting to use the DEC Line-Drawing Character Set, which is built into VT100s, VT320s, and any other DEC-like terminal built since 1980. With the proper character set mapped into the "alternate" character set, and if the terminal (or emulation) properly honors codeset switching, a horizontal line is displayed, instead of "qqqqqqqq...". (By the way, this is *not* the same as DEC's "advanced video option", or AVO. AVO on a VT100 gave you 24-line-by-132-column mode and the full four video attributes: underline, reverse, bold, & blink. Later DEC terminals had support for this as standard.) > With an xterm and TERM=vt100, the video is great (appears to use > the vt100 graphics character set to draw frames), but the > function keys didn't work. You don't say what kind of keyboard you are using. Makes a difference. > After copying the terminfo files to a local directory, > pointing COBTERMINFO and TERMINFO at the local directory, and > running the .src files through tic, the situation improved > slightly. The video for the aixterm and xterm with > TERM=xterm is better, but frames are drawn using +---+ > instead of the vt100 graphics characters. A reasonable thing to do, if the client cannot be certain that your xterm emulation supports the line-drawing characters. > I was able to modify the kf1 settings in vt100.src so that the function > keys are recognized, but the frames are drawn the same as > with the aixterm and xterm with TERM=xterm. > > I also pulled the example vt100 file from the Microfocus > Cobol home page and tried using this with an xterm. Same > results--no advanced video. > > If anyone has any terminfo files that appear to work in this > environment, or online documentation for the settings of sgr, > sgr0, enacs, rmacs, and acsc I'd really appreciate it. The global master database for terminfo and termcap descriptions is now maintained by Eric S. Raymond and is available from: http://www.ccil.org/~esr/ncurses.html [URL is now stale; try http://www.gnu.org/software/ncurses/ncurses.html] ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals,alt.folklore.computers Path: cs.utk.edu!gatech!psuvax1!news.cc.swarthmore.edu!netnews.upenn.edu !netaxs.com!esr Date: 23 Feb 1995 17:17:18 GMT Organization: Netaxs Internet BBS and Shell Accounts Lines: 117 Message-ID: <3iifuu$dan@netaxs.com> NNTP-Posting-Host: unix2.netaxs.com From: esr@netaxs.com (Eric Raymond) Subject: Questions about archaic terminals I've taken over (with his approval) the master termcap file from John Kunze at Berkeley. I've significantly reorganized and updated it, and am trying to clean up the cobwebs and dust in its neglected corners. This is the second posting of my standing questions about archaic terminals, which I'm posting to comp.terminals and to alt.folklore.computers (the latter because of its high percentage of old-timers). It really is shorter than the first posting -- thanks to everyone who answered last time. TERMINAL TYPE QUESTIONS 1. I'm looking for any information I can get (full name, manufacturer, approximate year of release and/or discontinuance) on the following: cad68-3|cgc3|cad68 basic monitor transparent mode size 3 chars: cad68-2|cgc2|cad68 basic monitor transparent mode size 2 chars: cdi|cdi1203: d800|Direct 800/A: ddr|rebus3180|ddr3180|Rebus/DDR 3180 vt100 emulator: I suspect this is "Digital Data Research" delta|dd5000|delta data 5000: digilog|333|digilog 333: ep48|ep4080|execuport 4080: ep40|ep4000|execuport 4000: These were portable thermal-printer ttys fit into suitcases, with a built in 15 or 30cps audio coupler. Anyone got a manufacturer name? ifmr|Informer D304: I have dim memories from c.1983 of a "lunchbox" portable terminal packaged like a smaller version of the Osborne-1 with a built-in 1200cps modem, that might have been this guy. Can anyone confirm this? modgraph|mod|Modgraph terminal emulating vt100, 24x80: Modgraph GX-1000: mt70|m70|morrow mt70: Was this from Morrow Designs, the microcomputer outfit? mw2|Multiwriter 2: Yes, this is (or was) a printing terminal. ps300|Picture System 300: tab132|tab|tab132/15|tab 132/15: tec400|tec scope: tec500|tec 500: tec: No, these are *not* Tektronix terminals! teletec|Teletec Datascreen: terak|Terak emulating Datamedia 1520: I think these guys used to make graphics frame buffers. v3220|LANPAR Vision II model 3220/3221/3222: wind: wind16: wind40: wind50: xitex|xitex sct-100: ubell|ubellchar: This may have been pronounced "Microbell". ttyWilliams: qdss: 4. The following entries are utterly mysterious to me: pty|pseudo teletype:\ :do=^J:co#80:li#24:am:cl=\EJ:le=^H:bs:cm=\EG%+ %+ :nd=\EC:\ :up=\EA:ce=\EK:cd=\EL:al=\EP:dl=\EN:ic=\EO:\ :so=\Ea$:se=\Eb$:us=\Ea!:ue=\Eb!: This is not a standard UNIX pty, which wouldn't have its own emulation. plasma|plasma panel:\ :am:le=^H:bs:cl=^L:co#85:ho=^^:li#45:nd=\030:up=\026:do=^J: Does anyone have any ideas about either of these? VENDOR STATUS QUESTIONS 1. I believe Hazeltine, Fortune Systems, Ann Arbor, Harris (the Beehive people), Intertec Data Systems, and Soroc are out of business. Can anyone confirm any of these? 2. Anyone have either Internet or snail addresses, or phone numbers, for the terminal-manufacturing groups at the following corporations? Visual, Control Data, Datamedia, IBM, General Terminal Corp., Kimtron, Microterm, Perkin-Elmer, Tektronix, Volker-Craig, Masscomp, General Electric, Southwest Technical Products, Cybernex. You can surf to the new terminfo file from my home page. It's at http://www.ccil.org/~esr/ncurses.html [Archiver's Note: the above URL is stale. As of June 2002, the following URL works: http://www.gnu.org/software/ncurses/ncurses.html ...RSS] If you are knowledgeable about async terminals, especially the older varieties, please look it over and email me any corrections or comments you have. -- Eric S. Raymond ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.sys.hp.hpux Message-ID: References: <351244A1.1BCE@nspuh.cz> Date: Fri, 20 Mar 1998 14:56:29 GMT From: Larry M Headlund Subject: Re: curses in 10.20 In article <351244A1.1BCE@nspuh.cz>, Michal Hajek wrote: > >I wrote program under 9.04, which uses curses and term. >When compiled under 9.04, it works correctly under both >9.04 and 10.20. > >But when I compile it under 10.20, I am in troubles: > a) attributes (reverse and so) do not works > (displayed text is not reversed ..) > b) term things (key_f1 and so) are not set. > >(I can not test it under 9.04, because of missing some >system libraries. Can it be compiled under 10.20 with >ability to be run under 9.04 ??) > >Where can be the problem ? Have you loaded all the patches? I encountered a similar problem when I upgraded a client in April 1997, but when I loaded the patches available at that date, the problem resolved itself. -- Larry Headlund lmh@world.std.com Mathematical Engineering, Inc. (617) 242 7741 Unix, X and Motif Consulting ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Message-ID: <3612e7c5.83730137@news.demon.co.uk> References: <3610C9E8.4294@yahoo.com> Date: Tue, 29 Sep 1998 14:02:57 GMT From: Harry Broomhall Subject: Re: Seeking a termcap entry for viewdata (Prestel or Minitel) On Tue, 29 Sep 1998 12:52:08 +0100, Simon Rawles wrote: >Hello to the readers of comp.terminals. > >A few days ago, I became the owner of an Alcatel viewdata terminal. It's >like a French minitel, but will also work with the British Prestel-like >systems. I've got it to connect to Silicon Village and other services, >but I'd like to get it working as a terminal for my Linux machine. > >Not surprisingly, there isn't a termcap for viewdata terminals supplied >with Linux. I say "not surprisingly" because this is not the normal type >of terminal. Control codes (change colour, flash on/off etc) each take >up the space of a character on the screen, so that each screen (or >'frame') is 1K (-ish). termcap seems to assume that control codes do not >take up screen space in this way, and I think that's why I am having >difficulty finding on. > >If anyone out there can help, that would be great. Send me a mail or >reply here. Otherwise, I am going to have a go at writing my own. But >I'd rather not write my own if someone else had done one already. Not sure quite what you are trying to do. If you want to use this terminal as a 'glass tty' type of thing then investigate the 'cookie-glitch' setting in TERMCAP. In reality, you will have a *lot* of problems getting this to work, as Viewdata has a number of 'features' that TERMCAP cannot handle. The chief one is that all control codes are reset to default at the end of a line. Regards Harry. ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.os.linux.development.system,comp.os.linux.setup, comp.os.linux.networking,comp.os.linux.misc,comp.sys.hp.hpux Message-ID: <36769A74.5F58696A@saic.com> Organization: SAIC/ITS/Server Support References: <36765D99.1DAAA5FC@usa.net> Date: Tue, 29 Dec 1998 02:09:35 GMT From: Bruce Mohler Subject: Re: hpterm client under RedHat5.X KONTO wrote: > Hello linux and hewlett packard people, > > I have to rlogin from a dozen of HP 700/RX X-Windows terminals to some > RedHat-5.2 PC-PII350MHz servers. How do you connect them ? > Need a termcap written for linux or something else, able to correct my hpterm > screens. ( making possible something as un "export TERM=hpterm" ) > I've always just FTP'd (binary mode) the terminfo entries from an HP system to the Linux boxes and they seem to work just fine. For example, on an HP-UX 10.20 system, copy /usr/share/lib/terminfo/d/dtterm (for CDE) and /usr/share/lib/terminfo/h/hpterm (for VUE) to the corresponding terminfo directories on your Linux boxen. Bruce -- Bruce W. Mohler 619-458-2675 (voice) SAIC/ITS/Server Support 619-535-7806 (fax) Sr UNIX system administrator 888-781-5697 (pager) mailto:bruce.w.mohler@saic.com Of course my password is the same as my pet's name. My dog's name is Q47pY!3, but I change it every 90 days. ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.sco.misc, comp.terminals Message-ID: <931932041.684820@iris.nyx.net> References: <3782309E.6B31E7AB@cencor.com> <378c328c.594621310@news-server.tampabay.rr.com> <378A35A9.6ED81147@cencor.com> Organization: Nyx Public Access Internet X-Trace: wormhole.dimensional.com 931932042 206.124.29.7 Date: Wed, 14 Jul 1999 06:00:42 GMT From: Craig Macbride Subject: Re: SCO Unix and 3151 Terminal Peter Gordon writes: > Apparently, CTRL-Home from a 3151 serves the same purpose as Delete on an > ANSI terminal. Unless your time is _incredibly_ cheap or you have a _massive_ number of these things, the long-term cheapest solution from a support point of view would be to throw the old crap out and buy some decent terminals. >SCO recommends making sure the TURNAROUND attribute of the terminal is set >to CR, >then editting and recompiling terminfo.src so that the function key strings >end in \r instead of \n. The SCO 5.0.5 terminfo entry has a comment that Turnaround should be CR, yet (incorrectly) has function key entries ending in \n. >It's my unserstanding that the app >should be consulting >terminfo/termcap to figure out what it is getting (the app is filepro) >Any additional advice from anyone? First thing: Halve your work by finding out whether your application is using terminfo or termcap. Then you'll only have one thing to play with. Next, find out whether the application is getting the terminal modes correctly. (Do an stty -a on the device port from elsewhere while in the app.) If the tty driver is still doing cr/lf translation, your app is written incorrectly and you'll have to deal with that problem. -- Craig Macbride -----------------------http://amarok.glasswings.com.au/~craig--------------- "It's a sense of humour like mine, Carla, that makes me proud to be ashamed of myself." - Captain Kremmen ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.programmer Date: Tue, 19 Jun 2001 08:53:50 -0500 From: Chuck Dillon Subject: Re: stty command-- what it does caroline wrote: > > hi, > can you please explain what stty does. > thanks, > caroline.c Terminal devices are highly configurable and their interfaces are standardized, so that they all look pretty much the same. In C code you use the ioctl() system call to read/change terminal settings. It is often necessary to be able to read/change terminal settings from a script. The stty program is a commandline interface that sits on top of ioctl() which allows you to script reading and/or changing of terminal settings. The man page for stty describes the capabilities, in stty terms, and it refers to other manpages (e.g. ioctl, termio ...) which describe the lower level stuff. HTH, -- ced -- Chuck Dillon Senior Software Engineer Accelrys Inc., a subsidiary of Pharmacopeia, Inc. ////////////////////////////////////////////////////////////////////////////// Message-ID: <7p98if$6al$1@nnrp1.deja.com> NNTP-Posting-Host: 208.242.14.200 Date: Mon, 16 Aug 1999 14:52:04 GMT From: Mark Greene Newsgroups: comp.terminals Subject: padding, terminfo, and DU4.0d I'm having a problem with the padding specified in the terminfo vt100 definition on an Alpha 8400 running DU4.0d. Specifically, the padding characters are displayed as $<5> instead of being acted upon. I connect via telnet, and have gotten the same results using both Reflection and Attachmate. Has anyone else seen this behavior? -- Mark ////////////////////////////////////////////////////////////////////////////// Message-ID: <7p9b8o$8i5$1@nnrp1.deja.com> References: <7p98if$6al$1@nnrp1.deja.com> Date: Mon, 16 Aug 1999 15:38:02 GMT From: Mark Greene Newsgroups: comp.terminals Subject: Re: padding, terminfo, and DU4.0d In article <7p98if$6al$1@nnrp1.deja.com>, Mark Greene wrote: [snip original] As a side note, I checked the man pages, and DU did not have any specific examples, or even very much mention of padding at all. AIX, OTOH, had this gem of wisdom: "To test for correct padding (if known), do the following: 1. Edit the /etc/passwd file at 9600 baud. 2. Delete about 16 lines from the middle of the screen. 3. Press the u key several times quickly. If the terminal fails to display the result properly, more padding is usually needed. You can perform a similar test for insert character. Note: Excessive padding slows down the terminal." Conspicuous lack of mentioning *not* to save the changes or to edit in read-only mode. :-( -- Mark ////////////////////////////////////////////////////////////////////////////// Message-ID: Organization: Clark Internet Services, Inc., Ellicott City, MD USA User-Agent: tin/pre-1.4-19990624 ("Dawnrazor") (UNIX) (SunOS/5.6 (sun4u)) Date: Mon, 16 Aug 1999 18:59:18 GMT From: "T.E.Dickey" Newsgroups: comp.terminals Subject: Re: padding, terminfo, and DU4.0d Mark Greene wrote: > I'm having a problem with the padding specified in the terminfo vt100 > definition on an Alpha 8400 running DU4.0d. Specifically, the padding > characters are displayed as $<5> instead of being acted upon. I connect > via telnet, and have gotten the same results using both Reflection and > Attachmate. Has anyone else seen this behavior? Perhaps the application (or library) doesn't recognize padding and is just writing the terminfo strings as-is rather than using tputs. -- Thomas E. Dickey dickey@clark.net http://www.clark.net/pub/dickey ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Date: 8 Feb 2000 18:00:58 +0100 Organization: [posted via] Leibniz-Rechenzentrum, Muenchen (Germany) Message-ID: From: Martin Ramsch Subject: Re: Drawing Boxes with ascii chars ? On Sat, 05 Feb 2000 00:00:04 GMT, Ake wrote: > > I'm currently writing a client-server application on a linux PC, > and i want the server to send the box-drawing codes to the clients. > If i understood what you said, every OS has different codes to display > those symbols, so,if i sent the right codes to every client they should > display them in the right way, shouldn't they ? Well, sending the right codes to do something always seems to be a reasonable thing, isn't it? :) Just in case you're programming in an Unix environment, there's a "terminal capabilities database" (termcap/terminfo) which holds the right codes for different terminal types. To get the right codes to switch to the so-called alternate character set including box-drawing codes, you just issue the commands tput enacs # enable alternate character set tput smacs # switch to acs mode echo "lwk" # echo "tnu" # Draw a little "cross window". echo "mvj" # tput rmacs # switch back to normal character set To be even more precisely you first should check for the 'acsc' capability to see which characters draw which box elements. Regards, Martin -- Martin Ramsch PGP KeyID=0xE8EF4F75 FiPr=5244 5EF3 B0B1 3826 E4EC 8058 7B31 3AD7 ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.questions References: Date: 4 May 2001 10:33:38 GMT Organization: RadixNet Internet Services Message-ID: <9cu0i2$4h$3@news1.Radix.Net> From: Thomas Dickey Subject: Re: $TERM wars fred smith wrote: > dumps the linux console terminfo to your screen. > You take it to the Sun box and insert it into the system by doing: > tic > e.g.; > tic linux.terminfo > You'll almost certainly need to be root to do this. no--if $TERMINFO is set, tic uses that as the directory under which it will try to install the description (it's in the terminfo manpage). So the terminfo database can be in your own directory. -- Thomas E. Dickey http://dickey.his.com ftp://dickey.his.com ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Message-ID: <9ktpqp$7ht$2@news1.Radix.Net> References: <3B7164AE.54AE2B19@rcn.com> Date: 9 Aug 2001 10:48:57 GMT From: Thomas Dickey Subject: Re: wyse85 function keys Jim wrote: > > I am a bit confused about the function keys on the terminal. There are > several entries for the wyse 85 in the terminfo base. ie: 80x25, 132x25 > Visual bell etc. The termcap file had no entries for this terminal. likely because termcaps have to be small (no larger than 1023 characters). > Initialy I set it up for a vt100 as that is the emulation the terminal > is set for. The function keys don't work. While some keys do work ie: > the arrow keys, backspace delete and such. The numerical keypad does not > work nor do any of the function keys. > > After a bit of searching, I came up with some termcap entries for the > terminal and pasted them into my existing termcap base. It sort of > works. The problem is, I have no way of knowing what those keys > generate. I could download a set of keys at terminal init via a script > but there must be better way to deal with the problem. If I change the > function keys in /etc/termcap do the entries in the terminfo have to > match or will termcap overide those descriptors? Is there as program I > can use to see what the keys generate from the terminal? termcap and terminfo are (usually) separate, and only one of them used by a given application. > At this point I won't get into the Relisys 175 I have waiting for > solutions. I have not been able to find information on that one for > sometime. I am hoping I can learn enough from dealing with the wyse85 to > help figuring out the Relisys. Any pointers to some good reading or tips > from experience would be appreciated.. -- Thomas E. Dickey http://dickey.his.com ftp://dickey.his.com ////////////////////////////////////////////////////////////////////////////// Archiver's Hint: To see what ASCII code sequences a given keyboard key produces: Use the Unix "od" command to see codes produced by pressing a key. Start "od", press the key, then type the Return key and Control-D. The following example features the VT100 PF1 key, which sends the control sequence "SS3 P" (where the SS3 code is "Escape O" in 7-bit; you probably know that the Escape code 1B is the same as Control-[). % od -c -x ^[OP 0000000 033 O P \n 1b4f 500a 0000004 (The "0a" is a Linefeed/Newline, which is how Unix thinks of the Return key.) So, we find that the VT100's PF1 (Gold) key emits the following hexadecimal values (in 7-bit mode): 1Bx 4Fx 50x An 8-bit PF1 key would emit 8Fx 50x but, since a real VT100 does not implement 8-bit mode, don't count on this being useful in an emulated-VT100 environment (although a real VT220 in 8-bit mode would emit this value). ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals References: <1001693588.8011.0.nnrp-14.c246f601@news.demon.co.uk> <3BB58551.8312BD41@ev1.net> <9p4e4i$mvg$3@news1.Radix.Net> <1002008440.20934.0.nnrp-13.c246f601@news.demon.co.uk> Message-ID: <9pcn60$4do$1@news1.Radix.Net> Organization: RadixNet Internet Services Date: 2 Oct 2001 15:40:48 GMT From: Thomas Dickey Subject: Re: Terminal problem with ncurses Julian Regel wrote: >> it sounds more as if he's setting $TERM to something that doesn't work - >> but the comment about "doesn't even get that far" can cover a lot more >> problems than that. > Sorry, I'll be more explicit (and include some more information I've > discovered since my original post). > The first thing the program does is an initscr() to initialise curses, > defines a window and clears the screen using wclear(). On the Linux console, > or using Daves Telnet (which supports the "linux" terminal type, the program > works without problems. It is also fine using the Windows 2000 telnet > application with TERM set to "ansi" or "vt220". > On other telnet applications, including Windows 98 telnet set to ansi, or > numerous other vt220 compatible emulators, the program doesn't get as far as > clearing the screen--it just sits there waiting and doesn't respond to user > input. This happens when TERM is set to vt220 or ansi. "waiting" where? (in the application, or in your login initialization). > The above suggests to me that ncurses on this version of Linux (Suse 7.0) > doesn't use the TERM variable. It also suggests that ncurses makes use of > some escape sequences that are compatible with ansi and linux, and that > Windows 2000 is a full[er] ansi-compliant emulator than Windows 9x (which I > understand to be horribly broken). Standard vtXXX emulation just doesn't > deliver the goods ... :-( > Would this sound about right? no (I've run w2k telnet against ncurses applications--as well as winnt's telnet which does indeed have problems, but neither behaves as you describe). -- Thomas E. Dickey http://dickey.his.com ftp://dickey.his.com ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals References: <9rs2pi$lv8$1@wanadoo.fr> Message-ID: <9rs58t$a98$1@news1.Radix.Net> Organization: RadixNet Internet Services Date: 1 Nov 2001 18:45:49 GMT From: Thomas Dickey Subject: Re: [ncurses]: why not the right colors ? Thomas Baruchel wrote: > > Brest, le jeudi 1er novembre > Hi, I try to use colors with ncurses. Under XTERM, all is OK. > Under console, I don't have the right color. I'd like to have exactly the > same colors on xterm or console, because they are important for my purpose > (the have a signification). I don't understand why: for instance, > init_pair(COLOR_YELLOW,COLOR_YELLOW,COLOR_BLACK) int init_pair(short pair, short fg, short bg); (the first parameter is not a color) > gives yellow/black on xterm and green/black on console. > I have blue (on console) instead of red, etc. That's in the ncurses faq. The current version of ncurses is 5.2 (20001021) There's an faq at http://dickey.his.com/ncurses/ncurses.faq.html > Besided, how can I handle 16 colors and not only 8 ? not on the console (except of course by treating bold as a range of colors) > I know my terminal can handle all that, because if I use VIM on > console and ask for the blue color, I have the blue one on xterm AND > on console. VIM on console also have 16 colors. -- Thomas E. Dickey ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Message-ID: <9s1bik$8rl$1@wanadoo.fr> Organization: Wanadoo, l'internet avec France Telecom Date: 3 Nov 2001 18:04:04 GMT From: Thomas Baruchel Subject: Is it possible to use readline with ncurses ? Brest, le samedi 3 novembre Wondering if you can open a window with ncurses/panel and make the user type something in this window with readline. I know you can do something like that with 'form', but just wondering ;-) -- ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals References: <9s1bik$8rl$1@wanadoo.fr> Message-ID: <9s404n$s6f$1@news1.Radix.Net> Organization: RadixNet Internet Services Date: 4 Nov 2001 18:07:19 GMT From: Thomas Dickey Subject: Re: Is it possible to use readline with ncurses ? Thomas Baruchel wrote: > Brest, le samedi 3 novembre > Wondering if you can open a window with ncurses/panel and > make the user type something in this window with readline. > I know you can do something like that with 'form', but just > wondering ;-) yes/no: readline's functions which talk to the terminal can all be replaced (in principle) so it could be integrated to use a curses interface. I don't know that anyone's done this, but the topic has been discussed more than once. -- Thomas E. Dickey ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals References: <9s3jnm$5bh$1@wanadoo.fr> Message-ID: <9s40b2$s6f$2@news1.Radix.Net> Organization: RadixNet Internet Services Date: 4 Nov 2001 18:10:42 GMT From: Thomas Dickey Subject: Re: [ncurses+panel] update_panels() + doupdate () Thomas Baruchel wrote: > Hi, I use ncurses + panel, I always use: > update_panels(); > (void) doupdate(); > after any print instruction. > My problem is the following: when I print something in a panel, > the refreshing works well. When I use printw (+scrollok) in order to > print something in the stdscr (under all panels), a kind of log > sequences which should scroll under the panels, I often have panels > which aren't visible any longer (they seem to be under the stdscr > though the man page says it isn't possible). I have no panel > associated with stdscr, because the man page says it has not to be. perhaps a simple test program showing the problem would help. (I don't know if it would be a problem in ncurses, or a general limitation of the panel library--so I'd check first to see what Solaris curses does, and compare to ncurses). -- Thomas E. Dickey http://dickey.his.com ftp://dickey.his.com ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.sys.hp.hpux, comp.unix.admin Message-ID: Date: Mon, 03 Dec 2001 14:32:05 GMT From: Chuck Mattern Subject: termcap null ops? I've been instructed to do something I think is neither good nor possible, as usual good is not important, possible is. Has anyone seen a way to use termcap to map a null op? We have some PC's running a Java telnet application which uses a vt220 emulation. As expected our users try to use keys on the keyboard like Insert, Delete, Home, End, etc. Most of these keys are interpreted as "garbage characters" because the escape sequence is not defined in the termcap the application uses and thus is interpreted as plain text. Oddly the upstream application freezes when it receives these characters so it's not just a matter of a person reading past ^[[2~. It is my opinion that the application (which I do not have control of, but another team does) should disable or map these keys appropriately. It is my mission to re-write our termcap so that the offensive keys are either null ops or mapped to something innocuous like a space key. Since termcap was designed to map capabilities it is my suspicion that "sit there and give the user a stupid look" is not one of the intended capabilities and neither "is insert a space", Delete of course can be handled but is there the capability to pipe delimit or tandem certain escape sequences as in some other mapping utilities, say for instance BS="^?|^H". Any suggestions welcomed, Chuck -- ---------------------------------------------------------------------- |Chuck Mattern | People often find it easier to be a result | |cmattern@mediaone.net | of the past than a cause of the future. | ---------------------------------------------------------------------- .............................................................................. Newsgroups: comp.sys.hp.hpux, comp.unix.admin References: Message-ID: <3C0BA8B2.458A1915@accelrys.com> Organization: Accelrys Inc. Date: Mon, 03 Dec 2001 10:30:42 -0600 From: Chuck Dillon Subject: Re: termcap null ops? Chuck Mattern wrote: > > I've been instructed to do something I think is neither good nor > possible, ... Termcap is just a database that describes the capability of a certain kind of device in generic terms. The purpose of termcap is to let an application, like the offending Java app, handle different kinds of terminal devices without the need of knowing any specific escape codes. To get filtering you need another process to do the mappings for you. There may be hope. You could use expect (http://expect.nist.gov/) to script a layer to recognize and filter the unsupported escape codes, map them to no-ops. You would need to develop an expect script to filter the unsupported escape codes. Then you would call the java app from a wrapper that fires up your expect script with the java app dircted to it. You end up with: java -> pseudo-ttya -> expect -> telnet-pseudo-tty -> telnet client -> network -> ... There are some examples at expect.nist.gov that involve terminal emulation and telnet. -- ced -- Chuck Dillon Senior Software Engineer Accelrys Inc., a subsidiary of Pharmacopeia, Inc. .............................................................................. Newsgroups: comp.sys.hp.hpux, comp.unix.admin References: <3C0BA8B2.458A1915@accelrys.com> Message-ID: Date: Mon, 03 Dec 2001 21:02:19 GMT From: Chuck Mattern Subject: Re: termcap null ops? Thanks for the followup Chuck. Actually, it's even uglier than it seemed. The offending Java app was selected to run on our "platform agnostic" Java desktop but (I suspect) it was found too late that all of these Java apps were being coded in a Microsoft-specific||dependant way and there was no way to get them to run on our anticipated Linux thin clients in time, so now the workstations are all Win2K. I doubt running an expect filter would be allowed, but it's nice to know that I'm not out in space here. Regards, Chuck .............................................................................. Newsgroups: comp.sys.hp.hpux, comp.unix.admin References: <3C0BE036.CBC4BEF3@boeing.com> Message-ID: Date: Tue, 04 Dec 2001 10:26:09 GMT From: Chuck Mattern Subject: Re: termcap null ops? Robert Gilster writes: > ---------------------------------------------------------- > We have similar problems when we have users client off of our VMS and > True64 machines. The HP has the keyboard mapped out like a standard PC, > but unfortunately the DEC machines still make the assumption that you're > sitting at a DEC keyboard--you know, the one that's so old it's got > gray hairs and has about 30 PF keys at the top and sides. To rectify > this problem we used `xmodmap` (man xmodmap) in conjunction with a > keymapping file to remap all the keys that were giving us grief. The > only glitch is that you have to know what keys you want to remap--but > it sounds like you do anyways. I can post my keymappings if you'd like-- > if you've never done it, it can be daunting. Many thanks for the offer. I've been down the xmodmap road before, indeed daunting, but once travelled not too bad. Saddly not only have my superior opted for a Java telnet application, they have also opted to run it on Win2K. We are using Win2K as a workstation going to an HP that runs the bulk of the applications (mostly Informix 4GL). My task is to make the make a translation in the middle so that neither the Win2K Java folk nor the Informix 4GL folk will need to make any mods to their code. Regards, Chuck -- ---------------------------------------------------------------------- |Chuck Mattern | People often find it easier to be a result | |cmattern@mediaone.net | of the past than a cause of the future. | ---------------------------------------------------------------------- ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.programmer Message-ID: <20020124.172528.1139901474.2807@schlund.de> References: <20020124094051.455b48cc.tberkopes@indy.rr.com> <7HV38.189$Ab1.11149@bgtnsc04-news.ops.worldnet.att.net> <20020124104410.4dc54ea9.tberkopes@indy.rr.com> Organization: Schlund + Partner AG Date: Thu, 24 Jan 2002 17:25:28 +0100 From: Norbert Kaufmann Subject: Re: ncurses In article <20020124104410.4dc54ea9.tberkopes@indy.rr.com>, "TonyB" wrote: > The code came from 'NCURSES HOW-TO'. I did 'copy/paste', the code and > had to be cleaned up so it would compile. Refresh was called. The code > worked when I was NOT in X. I just wondered why I could not see the > output while in X and a xterm shell........ > does your xterm support curses? maybe you have to change your .Xdefaults xterm*set-cursesemul: on please take a look at your xterm manpage. norbert ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals References: <32CCC4FB.DFA6041B@yahoo.com> <32D2E960.18AB7B2E@yahoo.com> Message-ID: Organization: RadixNet Internet Services Date: 19 Jun 2002 00:09:22 GMT From: Thomas Dickey Subject: Re: Dec VT220 backspace help Paul Williams wrote: > Simon Coombs wrote in > news:aelnbj$9gr$1@nenevr.demon.co.uk: >> The Termcap that comes with Slackware has been a little buggy for at >> least as long as I've been using it (since version 2.2) with regards >> the vt100 entry, although it does appear to have become more >> pronounced in recent versions... (this is being typed on a machine >> with a Slack 8.0 distribution on it.) > Naive question number 37: are all termcaps and terminfos not the same, > then? I just assumed that they would come from ESR's master database. The large one we're talking about is probably ESR's version 9-something which is in a lot of places. It's older than what's in ncurses. A somewhat newer version (than the 9.x) is in current GNU termcap, though I've pointed out that ncurses' has improvements over that. ftp://invisible-island.net/ncurses/terminfo.src.gz ftp://invisible-island.net/ncurses/termcap.src.gz > (I'm not trying to be funny -- I've only just started using text terminals > on Linux, for work. In fact I've only just bought the O'Reilly book on the > subject. Talk about trailing edge!) ...and it doesn't discuss color and other interesting stuff. (But it's the only good reference in print that I'm aware of). > - Paul -- Thomas E. Dickey http://dickey.his.com ftp://dickey.his.com ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals References: <32CCC4FB.DFA6041B@yahoo.com> <32D2E960.18AB7B2E@yahoo.com> Message-ID: Organization: RadixNet Internet Services Date: 19 Jun 2002 00:02:51 GMT From: Thomas Dickey Subject: Re: Dec VT220 backspace help Simon Coombs wrote: > Thomas Dickey wrote: >> for example? (the problems, that is) > From my /etc/termcap: > vt100|dec-vt100|vt100-am|vt100am|dec vt100:\ > :do=^J:co#80:li#24:cl=50\E[;H\E[2J:sf=2*\ED:\ ^^ ^^ > :le=^H:bs:am:cm=5\E[%i%d;%dH:nd=2\E[C:up=2\E[A:\ ^^ > :ce=3\E[K:cd=50\E[J:so=2\E[7m:se=2\E[m:us=2\E[4m:ue=2\E[m:\ > :md=2\E[1m:mr=2\E[7m:mb=2\E[5m:me=2\E[m:is=\E[1;24r\E[24;1H:\ > :if=/usr/share/tabset/vt100:\ > :rs=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h:ks=\E[?1h\E=:ke=\E[?1l\E>:\ > :ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:kb=^H:\ > :ho=\E[H:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:pt:sr=2*\EM:vt#3:xn:\ > :sc=\E7:rc=\E8:cs=\E[%i%d;%dr: > Note the numbers in front of the entries cl, sf, ce, cd, so, etc. etc. > The Termcap that comes with Slackware has been a little buggy for at > least as long as I've been using it (since version 2.2) with regards > the vt100 entry, although it does appear to have become more > pronounced in recent versions... (this is being typed on a machine > with a Slack 8.0 distribution on it.) My understanding is that the leading numbers on a termcap string are an (obsolete--relative to termcap) way of expressing padding. For example, here's what Solaris' infocmp renders for a vt100 into termcap: # Reconstructed via infocmp from file: /export/home/dickey/lib/terminfo/v/vt100 vt100|vt100-am|dec vt100 (w/advanced video):\ :am:mi:ms:xn:xo:bs:pt:\ :co#80:it#8:li#24:vt#3:\ :@8=\EOM:DO=\E[%dB:K1=\EOq:K2=\EOr:K3=\EOs:K4=\EOp:\ :K5=\EOn:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:\ :ac=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~:\ :ae=^O:as=^N:bl=^G:cb=3\E[1K:cd=50\E[J:ce=3\E[K:\ ^^ :cl=50\E[H\E[J:cm=5\E[%i%d;%dH:cr=\r:cs=\E[%i%d;%dr:\ ^ :ct=\E[3g:do=\n:eA=\E(B\E)0:ho=\E[H:k0=\EOy:k1=\EOP:\ :k2=\EOQ:k3=\EOR:k4=\EOS:k5=\EOt:k6=\EOu:k7=\EOv:\ :k8=\EOl:k9=\EOw:k;=\EOx:kb=\b:kd=\EOB:ke=\E[?1l\E>:\ :kl=\EOD:kr=\EOC:ks=\E[?1h\E=:ku=\EOA:le=\b:mb=2\E[5m:\ :md=2\E[1m:me=2\E[m^O:mr=2\E[7m:nd=2\E[C:\ :r2=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h:rc=\E8:\ :.sa=!!! MUST CHANGE BY HAND !!!\E[0%?%p1%p6%|%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;m%?%p9%t^N%e^O%;:\ :sc=\E7:se=2\E[m:sf=\n:so=2\E[1;7m:sr=5\EM:st=\EH:\ :ta=\t:ue=2\E[m:up=2\E[A:us=2\E[4m: which corresponds to a terminfo entry where the numbers are on $ form: # Reconstructed via infocmp from file: /export/home/dickey/lib/terminfo/v/vt100 vt100|vt100-am|dec vt100 (w/advanced video), am, mir, msgr, xenl, xon, cols#80, it#8, lines#24, vt#3, acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~, bel=^G, blink=\E[5m$<2>, bold=\E[1m$<2>, clear=\E[H\E[J$<50>, cr=\r, csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=\b, cud=\E[%p1%dB, cud1=\n, cuf=\E[%p1%dC, cuf1=\E[C$<2>, cup=\E[%i%p1%d;%p2%dH$<5>, cuu=\E[%p1%dA, ^ cuu1=\E[A$<2>, ed=\E[J$<50>, el=\E[K$<3>, ^^^^ el1=\E[1K$<3>, enacs=\E(B\E)0, home=\E[H, ht=\t, hts=\EH, ind=\n, ka1=\EOq, ka3=\EOs, kb2=\EOr, kbs=\b, kc1=\EOp, kc3=\EOn, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA, kent=\EOM, kf0=\EOy, kf1=\EOP, kf10=\EOx, kf2=\EOQ, kf3=\EOR, kf4=\EOS, kf5=\EOt, kf6=\EOu, kf7=\EOv, kf8=\EOl, kf9=\EOw, rc=\E8, rev=\E[7m$<2>, ri=\EM$<5>, rmacs=^O, rmkx=\E[?1l\E>, rmso=\E[m$<2>, rmul=\E[m$<2>, rs2=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h, sc=\E7, sgr=\E[0%?%p1%p6%|%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;m%?%p9%t^N sgr0=\E[m^O$<2>, smacs=^N, smkx=\E[?1h\E=, smso=\E[1;7m$<2>, smul=\E[4m$<2>, tbc=\E[3g, > As you can imagine, this leads to some fairly interesting results > from time to time...! ncurses does know about the numbers if it's configured (as Slackware does iirc) for BSD-padding. In the code that's ifdef'd with BSD_TPUTS. I don't recall if GNU termcap recognizes that syntax, and of course home-brew stuff like 'joe' has no guarantee whatever... Now that I'm looking at it (and comparing ncurses' output on another machine), I recall some issue about ncurses not rendering the non-mandatory delays in translation to termcap. (will have to check/see if that's intentional). Anyway--it doesn't on the machine I'm looking at. > I really ought to get round to straightening it out some day soon. In > the meantime, I'll stick to using the vt320 entry. >:) That doesn't use padding. (Actually it's not a technically good entry, but lots of people use it, so I can't really fix it w/o getting lots of email ;-) -- Thomas E. Dickey http://dickey.his.com ftp://dickey.his.com ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.solaris NNTP-Posting-Host: 62.177.151.68 References: <45142724.4050401@gomonarch.com> Message-ID: <45142cbc$0$4513$e4fe514c@news.xs4all.nl> Organization: Sun Microsystems, Netherlands Date: 22 Sep 2006 18:34:36 GMT From: Casper H.S. Dik Subject: Re: terminfo source for "ansi" Solaris 10 Wayne Rasmussen writes: > >Hello, > >Trying to find the source for /usr/share/lib/terminfo/a/ansi. Anyone >know where I can get this? $ infocmp ansi # Reconstructed via infocmp from file: /usr/share/lib/terminfo/a/ansi ..... Or here: http://cvs.opensolaris.org/source/xref/on/usr/src/cmd/terminfo/ansi.ti -- Casper ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Message-ID: Organization: Hofheim/Taunus, Germany Date: 22 Jun 2002 20:27:42 GMT From: Joerg Klemenz Subject: Terminal will not input Umlaut correctly Hi group, I have a Termtek TK 725. I use it with the VT220-8 emulation with german keyboard. I have TERM=vt220, but the error occours also with TERM=xterm and ansi. I can enter german Umlaute in the bash shell, but when I load sh, csh, vi or any other programm it will display |-v-d when i type ue-oe-ae. This is *not* a charset error: The actual chars |vd will be entered! (substitute the uoa umlaute for ue...) In bash, I can type "echo ue-oe-ae > foo" and "vi foo" and vi will display the umlaute correctly, but i cannot enter any (I can yank and put then however) I can also call the Terminal setup with Alt-Esc and enter Umlaute in the input fields. I have a vague idea that the error is in NetBSD's notoriously bad termcap file. Do you have any idea where I can get better termcap files? Any suggestions will be highly appreciated TIA, joerg ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals References: <8ef44c8eafa869a6@mayday.cix.co.uk> Message-ID: Organization: Hofheim/Taunus, Germany Date: 24 Jun 2002 19:20:55 GMT From: Joerg Klemenz Subject: Re: Terminal will not input Umlaut correctly Robert de Bath wrote: > On 22 Jun 2002, Joerg Klemenz wrote: > > > Hi group, > > any other programm it will display |-v-d when i type ue-oe-ae. > > > $ stty -istrip ^^^^^^^^^^^^ Thats it Thanks for the answer joerg ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals References: Message-ID: Organization: RadixNet Internet Services Date: 2 Jul 2002 10:35:02 GMT From: Thomas Dickey Subject: Re: Urlview broken? Joerg Klemenz wrote: > Thomas Dickey wrote: >> Joerg Klemenz wrote: >>>> >>>> mutt probably is reading terminfo, not termcap (except on certain platforms >>>> where ncurses has been butchered to make termcap look more appealing ;-) >> >>> It's reading termcap My tk725 definition exists only in ~/.termcap, as I >>> said. And it works well[*]. Mutt and Vim run in color with it >> your copy of mutt is probably linked with slang, which has a built-in, > No it's not. See ldd output below It doesn't tell me everything--if you're linking against static libraries, ldd won't reflect that. OTOH, the absence of a curses or other recognizable term-library in ldd's output points to the use of static libraries, and your comments about mutt vs ~/.termcap seem to match slang. >> but incomplete termcap implementation. Here're the tradeoffs: ncurses, >> if configured (this is an option ;-), will read termcap. But termcap, >> like terminfo (and this is a feature _not_ supported by slang), may >> contain "tc=" clauses (in terminfo, "use=") which allow one to build >> up complex entries by combining simpler ones. Resolving those requires >> storing the whole termcap file somewhere--and on small machines, memory >> is a problem. So ncurses simply compiles it into ~/.terminfo (which >> it consults before termcap, of course). Since that's too much work for >> slang, it checks for that, and then tries the terminfo anyway. > I'm not sure if I understood that, but slang works with tc= here I was reading the source code when I made the comment. It occurred to me to wonder how slang dealt with that--since the "tc=" clauses can be forward references which would require it to store everything in memory. For small user-termcaps that's probably not an issue--the interesting one is in how it can deal with /etc/termcap. So now I know that slang cannot (in general) read that file either. For example, on Solaris where I am not, that means that slang can read less than half of the file before giving up and using terminfo. (If I had a program feature that worked only half the time, I would not advertise it widely ;-) Here's what the code (sltermin.c) says: termcap = (unsigned char *) getenv ("TERMCAP"); if ((termcap == NULL) || (*termcap == '/')) return -1; /* We have a termcap so lets use it provided it does not have a reference * to another terminal via tc=. In that case, use terminfo. The alternative * would be to parse the termcap file which I do not want to do right now. * Besides, this is a terminfo based system and if the termcap were parsed * terminfo would almost never get a chance to run. In addition, the tc= * thing should not occur if tset is used to set the termcap entry. */ t = termcap; while ((len = tcap_extract_field (t)) != -1) { if ((len > 3) && (t[0] == 't') && (t[1] == 'c') && (t[2] == '=')) return -1; t += (len + 1); } >> (Again, its implementation of terminfo is limited, but happens to work >> if ncurses is installed ;-) >> >> I hadn't thought about slang's implementation of this for a while, and >> see that it's worse than I recalled (including a bogus comment about >> XFree86 xterm--if it were accurate, it should have been a bug report ;-) > I just read in the slang docs yesterday, and I'm beginning to get a > clue. > But what do you mean with "if ncurses installed?" Does slang uses > ncurses? more often than not, slang uses the terminfo database which is installed as part of ncurses. It has its own cut-down version of a terminfo-reader, but since there is no binary-standard for terminfo, it happens to work with ncurses (which is designed to match Solaris) and in turn IRIX (I think for the same reason ;-). It won't work properly with HPUX, AIX, Tru64. In particular, colors and graphic characters are affected. > I should stop downloading that damn precompiled binaries and compile > everything myself. it's a good idea, for things that you customize-- > I think slang uses termcap on my system, and that that is the reason > it works so badly. > When I compile the stuff I will make it use terminfo and we'll see... > Am I right if I assume that I can make curses based apps like mutt use > ncurses instead and the app will use terminfo then? yes--in fact, compiling with ncurses is the default. > As a bizarre sidenote, I discovered that slang-based apps return a > different string for the arrow keys than others. > For example if I run vi and enter <^V> it says ^[OA, in > jed it says ^[[C. How strange is that? (under X-Windows, rxvt) Actually ^[[A. The ^[O and ^[[ strings prefixes are for the strings sent in application- and normal- modes of the terminal. For various obscure reasons (including convention), the application mode is preferred when running a full-screen program. >> what does tk725 look like, anyway? (for my collection...) > it looks like a vt220 termcap entry with individual fields changed by > some idiot who doesn't know a f*ck about all this two-letter stuff > But it's improving and I'll send you when im finished. thanks--comments to explain the changes are also helpful. > BTW: I just created new entry for the NetBSD console. By default > it uses the vt220 entry, but the function and cursor keys are > different. The wsvt25 says it needs to be redone. And it needs! > Am I really the first one who noted that??? I've seen some occasional comments about wsvt25, but have the impression that FreeBSD/NetBSD/OpenBSD have their own flavors of the console emulators. (It would be nice if there were one version). >>> I created terminfo files from my .termcap with tic and now Urlview works >>> fine. >> >>> Now I also know why: >>> ldd `which urlview` >>> /usr/pkg/bin/urlview: >>> -lncurses.5 => /usr/pkg/lib/libncurses.so.5 >>> -lc.12 => /usr/lib/libc.so.12 >> >> it gets worse--seeing that you're on one of the *BSD's... > Why is that worse? Enlighten me! I see a lot of comments indicating build problems when using the *BSD package system. ld's shared library resolution has trouble distinguishing the packaged libncurses from what's in /usr/lib. In FreeBSD 5.x, they've merged the package in--but (from reading comments-- I only have a 4.1) overridden the ifdef's so ncurses terminfo is stored where applications expect to see termcap. (It's not clear to me if the terminfo entries have been also cut-down to termcap size--but since the cgetent stuff is documented to support only 1023-byte buffers, it's possible that this was done as well). >>> ldd `which mutt` >>> /usr/pkg/bin/mutt: >>> -lcurses.3 => /usr/lib/libcurses.so.3 >> >> that must be interesting if you're using color... > Why is this supposed to be "interesting"? iirc, the .3 version of ncurses is the patched 1.8.6, whose color support is less than good. There were a number of back-ports of patches from later versions, but the end result is not good for applications such as mutt which use a lot of color. Generally--the background color isn't done properly. (But perhaps 4.5 has more patches to fix that). All of this stuff was fixed in ncurses in 1996, and refined over the next year or so. > Mutt works very well. In color and everything. In fact it is just > about the only program that always works... (besides vi) > slrn and jed (slang) will not work in color (console or terminal) or > not work at all :( > Is this because slang uses termcap or curses? I'm not sure w/o more info. > I will have to recompile them to use terminfo and see what happens... >>> -lssl.1 => /usr/lib/libssl.so.1 >>> -lcrypto.0 => /usr/lib/libcrypto.so.0 >>> -liconv.2 => /usr/pkg/lib/libiconv.so.2 >>> -lintl.1 => /usr/pkg/lib/libintl.so.1 >>> -lc.12 => /usr/lib/libc.so.12 >> >>> Mutt uses curses (->termcap) urlview uses ncurses (->terminfo). > joerg > -- > SMASH THE STATE > -- jk. -- Thomas E. Dickey http://dickey.his.com/ ftp://dickey.his.com/ ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals References: Message-ID: Organization: Hofheim/Taunus, Germany Date: 2 Jul 2002 23:46:28 GMT From: Joerg Klemenz Subject: Re: Urlview broken? Thomas E. Dickey wrote: > >> No it's not. See ldd output below > > It doesn't tell me everything--if you're linking against static libraries, > ldd won't reflect that. OTOH, the absence of a curses or other recognizable > term-library in ldd's output points to the use of static libraries, and your > comments about mutt vs ~/.termcap seem to match slang. I can't follow you here. Mutt is linked against curses. Nothing is statically linked in /usr/* -lcurses.3 => /usr/lib/libcurses.so.3 > I was reading the source code when I made the comment. It occurred to me to > wonder how slang dealt with that--since the "tc=" clauses can be forward > references which would require it to store everything in memory. For small > user-termcaps that's probably not an issue--the interesting one is in how > it can deal with /etc/termcap. So now I know that slang cannot (in general) > read that file either. For example, on Solaris where I am not, that means > that slang can read less than half of the file before giving up and using > terminfo. (If I had a program feature that worked only half the time, I > would not advertise it widely ;-) Now I can see. That is weird. Now I know why the FAQ recommends "tset -s". The tset that I have resolves the tc= clause and puts the complete entry in the TERMCAP env variable (with tc= replaced by the target...). That would enable slang to work with tc=, if one has a tset that does the work of parsing the termcap file... But why does slrn works with my home made termcap entry where there is no terminfo equivalent when there is tc= in it? I do *not* have TERMCAP set. slrn *will* work with a /usr/share/misc/termcap entry that is made up from tc= clauses. I don't understand enough about slang to know that. It *does* parse the termcap file here, unlike what the code says. Also slrn is linked with libtermcap here. termcap(3) indicates that tgetent() will search TERMCAP, ~/.termcap and /usr/share/misc/termcap. It also hints that tgetent() resolves the tc= clause. That description matches with slrn's behaviour here. It seems like slrn uses NetBSD libtermcap to read in a termcap entry. Could it be that the comment from the code regarding tc= refers only to the case where slrn/slang is _not_ linked with libtermcap and uses build-in primitives? Maybe there is code is slrn that uses slang's termcap "emulation" only if it is not linked with libtermcap or -info... So in my case the code below would never be called. > ... > but since there is no binary-standard for terminfo, it happens to work with > ncurses (which is designed to match Solaris) and in turn IRIX (I think for > the same reason ;-). It won't work properly with HPUX, AIX, Tru64. In > particular, colors and graphic characters are affected. There is no binary standard for terminfo?? So slang will read only the binary "standard" defined by ncurses? > > yes--in fact, compiling with ncurses is the default. I will have to try compiling everything with ncurses and read some sources then. I think there's nothing on televison on the weekend... I very much would like to think that this will fix the annoying display bugs in mutt, slrn, jed... > Actually ^[[A. The ^[O and ^[[ strings prefixes are for the strings sent in > application- and normal- modes of the terminal. For various obscure reasons > (including convention), the application mode is preferred when running a > full-screen program. But then slang seems to be "the only one" that uses application mode. Why does rxvt has to send differnt strings for normal- and application-mode? That seems absurd. What sort of people designed this systems anyway? And how does an application know that strings are send in application mode if only the normal mode is defined in termcap/terminfo files? Why am I asking this anyway... I am scared of the answer > > I've seen some occasional comments about wsvt25, but have the impression > that FreeBSD/NetBSD/OpenBSD have their own flavors of the console emulators. > (It would be nice if there were one version). Tell me about it. NetBSD has at least 2 different "consoles" that are largely incompatibe. Wscons is not used by all ports (CPU Architectures) I have been informed that the new version (1.6) will have a fixed termcap entry. Personally I think it would be better to fix wscons to work like a real vt220 plus color etc. I will do it RSN... > In FreeBSD 5.x, they've merged the package in--but (from reading comments-- > I only have a 4.1) overridden the ifdef's so ncurses terminfo is stored where > applications expect to see termcap. (It's not clear to me if the terminfo > entries have been also cut-down to termcap size--but since the cgetent stuff > is documented to support only 1023-byte buffers, it's possible that this was > done as well). Oh yes.. all these packages made by incompetent people :) If you think _that_ sucks then get yourself a copy of SuSE Linux... > iirc, the .3 version of ncurses is the patched 1.8.6, whose color support ^^^ You probably meant curses? > is less than good. There were a number of back-ports of patches from later > versions, but the end result is not good for applications such as mutt which > use a lot of color. Generally--the background color isn't done properly. I noticed that! > (But perhaps 4.5 has more patches to fix that). All of this stuff was fixed > in ncurses in 1996, and refined over the next year or so. Wasn't curses declared "obsolete" in 1995 or so? Everyone was supposed to use ncurses, right? > I'm not sure w/o more info. > >> I will have to recompile them to use terminfo and see what happens... BTW: I just adopted my /var/spool/slrnpull/score for this thread :) [*] Score:: -1000 Lines: 500 ^^^ joerg ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals References: Message-ID: Organization: RadixNet Internet Services Date: 3 Jul 2002 09:38:48 GMT From: Thomas Dickey Subject: Re: Urlview broken? Joerg Klemenz wrote: > I can't follow you here. Mutt is linked against curses. Nothing is > statically linked in /usr/* > -lcurses.3 => /usr/lib/libcurses.so.3 for some reason I missed that line (the ldd output was split up in the followup I was reading--sorry). > Now I can see. That is weird. > Now I know why the FAQ recommends "tset -s". The tset that I have > resolves the tc= clause and puts the complete entry in the TERMCAP env > variable (with tc= replaced by the target...). > That would enable slang to work with tc=, if one has a tset that does > the work of parsing the termcap file... ncurses doesn't, though... (the -S option of ncurses doesn't generate a $TERMCAP value). I suppose FreeBSD/... does, of course. > slrn *will* work with a /usr/share/misc/termcap entry that is made up > from tc= clauses. I don't understand enough about slang to know that. > It *does* parse the termcap file here, unlike what the code says. On the BSD's, /usr/share/misc/termcap is a hashed database, not a text file. > Also slrn is linked with libtermcap here. OK--in that case, the local implementation of libtermcap is doing the work. I'm more familiar with the way slang is configured on Linux and Unix hosts of course. Except for the 3 BSD's, no one uses termcap as the main terminal repository any more, so it's all in terms of terminfo, with a termcap library provid