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 provided for legacy apps. > 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. yes, that seems likely. >>> But what do you mean with "if ncurses installed?" Does slang uses >>> ncurses? not directly: > There is no binary standard for terminfo?? yes. Most of the implementations follow roughly the same layout (since they started at the same point in the 80's), but diverged. The actual layout in ncurses is built at compile-time from a text file which can be replaced. I've made a few customized flavors of that (aix4, osf1r5, uwin) which can be used to make ncurses use the host's terminfo database instead of its own. For instance I built ncurses that way on the machine I use for archiving lynx, so I could compare it with the host's implementation of curses. When I do that, slang cannot display colors. > So slang will read only the binary "standard" defined by ncurses? actually as defined on Solaris. It doesn't read the extensions that I added to ncurses a few years ago. (The extensions are on the end of the file, and appear to not conflict with any of the Unix implementations). > I very much would like to think that this will fix the annoying > display bugs in mutt, slrn, jed... It may--but there are other possibilities. I've seen comments that the BSD's don't have (really) good locale support. slang tends to ignore that anyway. > But then slang seems to be "the only one" that uses application mode. No--that's done by convention. curses applications send the terminal initialization string, which usually puts the special keys (cursor and keypad) into 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? back in the 70's... The vt100 came out around the time that people were trying to standardize this stuff. It was compatible with vt52 (both DEC) whose escape sequences for cursor were closer (still not identical) if running in normal mode. (I used both types of terminals and would for instance parse the cursor strings by ignoring punctuation characters and O's - it worked). Around the same time, there also were terminals that would not send anything for the cursor unless it were in application mode. The people who put the terminal descriptions together combined common features from these and other terminals and that formed the conventions we still use. > And how does an application know that strings are send in application > mode if only the normal mode is defined in termcap/terminfo files? It doesn't--it only recognizes the strings if they match. Some apps may have hardcoded tables of strings that they can use in case the terminal is in a different mode. When I started working with this stuff--actually looking at escape sequences--in 1984, curses didn't have any support for cursor keys. I was programming on VMS and BSD 4.1 around then, and neither did, actually. > Why am I asking this anyway... I am scared of the answer > 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 experimented with both, a few years ago, on FreeBSD but was not impressed. > Oh yes.. all these packages made by incompetent people :) If you think > _that_ sucks then get yourself a copy of SuSE Linux... Over here, Redhat seems to have that position filled. (I run Redhat occasionally to view bugs in their native habitat, Slackware or Debian to do work). >> iirc, the .3 version of ncurses is the patched 1.8.6, whose color support > ^^^ > You probably meant curses? sort of. 1.8.6 on FreeBSD was an early port--before I was involved with ncurses. I've also seen reference to a port to Minix around the same time. But I was thinking in terms of FreeBSD. I have a copy of NetBSD also--haven't been there in a few months--it's possible that your copy of mutt is linked with its curses. That one started as BSD curses and some people started rewriting it, adding features from X/Open curses such as ncurses--but it's incomplete and buggy. >> 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! I would immediately, since that, and resizing are my original reasons for working on ncurses. >> (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? The "obsolete", I'm afraid, was Eric Raymond's wording, which we all have to take his word for. (View it as a marketing statement ;-). I left some of that stuff in the documentation, more because it is amusing, than because it is accurate. -- Thomas E. Dickey http://dickey.his.com ftp://dickey.his.com ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals References: Message-ID: Organization: Hofheim/Taunus, Germany Date: 5 Jul 2002 00:02:16 GMT From: Joerg Klemenz Subject: Re: Urlview broken? Thomas Dickey wrote: > > Joerg Klemenz wrote: >> 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. What does "tset -s" do for ncurses then? >> 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. > > On the BSD's, /usr/share/misc/termcap is a hashed database, not a text file. Nope. termcap.db is hashed, termcap is just a plain text file The db file is created with cap_mkdb on NetBSD (they seem to have a fascination for commands w/ underscore). cap_mkdb also expands the tc capabilities, so my comments about getcap() were wrong: getcap expands tc only when reading from the termcap text file, when termcap.db exists the tc's are already expanded. You learn every day... >> There is no binary standard for terminfo?? > > yes. Most of the implementations follow roughly the same layout (since they > started at the same point in the 80's), but diverged. The actual layout in > ncurses is built at compile-time from a text file which can be replaced. I've > made a few customized flavors of that (aix4, osf1r5, uwin) which can be used > to make ncurses use the host's terminfo database instead of its own. For > instance I built ncurses that way on the machine I use for archiving lynx, > so I could compare it with the host's implementation of curses. When I do > that, slang cannot display colors. Can't you set TERMINFO to the dir with ncurses termcap files before you run a slang app? And then unset it afterwards to use the default? >> I very much would like to think that this will fix the annoying >> display bugs in mutt, slrn, jed... > > it may--but there are other possibilities. I've seen comments that the > BSD's don't have (really) good locale support. slang tends to ignore that > anyway. Huh? NetBSD has *bad* locate support, but FreeBSD is pretty good I think... What does locate support has to do with curses or display bugs? >>>> 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. > >> But then slang seems to be "the only one" that uses application mode. > > no--that's done by convention. curses applications send the terminal > initialization string, which usually puts the special keys (cursor and > keypad) into application mode. But this behaviour continous even when I comment out the is= capability. Could it be that *slang* puts the terminal in application mode, no matter what is in the termcap file? I guess I have to analyze that some day... >> And how does an application know that strings are send in application >> mode if only the normal mode is defined in termcap/terminfo files? > > It doesn't--it only recognizes the strings if they match. Some apps may have > hardcoded tables of strings that they can use in case the terminal is in a The more you know the more you wonder why your computer works at all... >>> iirc, the .3 version of ncurses is the patched 1.8.6, whose color support >> ^^^ >> You probably meant curses? > > sort of. 1.8.6 on FreeBSD was an early port--before I was involved with > ncurses. I've also seen reference to a port to Minix around the same time. > But I was thinking in terms of FreeBSD. I have a copy of NetBSD also--haven't > been there in a few months--it's possible that your copy of mutt is linked > with its curses. That one started as BSD curses and some people started > rewriting it, adding features from X/Open curses such as ncurses--but it's > incomplete and buggy. The NetBSD people think so about ncurses too :) I have been informed that NetBSD uses its own curses implementation which is not "classic" BSD curses and has been created by NetBSD developers. But you read that already on tech-userlevel... I'm getting a little behind in reading and posting and mailing But I know better now... joerg -- We're all looking for a woman who can sit in a mini-skirt and talk philosophy, executing both with confidence and style. ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals References: Message-ID: Date: 5 Jul 2002 09:58:47 GMT From: Thomas Dickey Subject: Re: Urlview broken? Joerg Klemenz wrote: > What does tset -s do for ncurses then? That's two options being referenced here (I think based on an implementation for SVr3). tset generates shell commands which can be executed: -S would set a $TERMCAP variable. -s sets a $TERM variable. (perhaps *BSD's tset combines the two--its manpage should say). >> On the BSD's, /usr/share/misc/termcap is a hashed database, not a text file. > > Nope. termcap.db is hashed, termcap is just a plain text file I tend to ignore the text-file since their termcap library also does. afaik, it is only there as a convenience to rebuild the hashed database. > Can't you set TERMINFO to the dir with ncurses termcap files before > you run a slang app? you seem to be referring to the text files--those aren't installed. > Huh? NetBSD has *bad* locate support, but FreeBSD is pretty good I > think... > What does locate support has to do with curses or display bugs? "locale", aka i18n. not "locate". > Could it be that *slang* puts the terminal in application mode, no matter > what is in the termcap file? what about rs= ? (the reset strings are more likely to be used than initialization strings) > The more you know the more you wonder why your computer works at all... ;-) >> with its curses. That one started as BSD curses and some people started >> rewriting it, adding features from X/Open curses such as ncurses--but it's >> incomplete and buggy. > The NetBSD people think so about ncurses too :) (it shows how little they know about the general topic area ;-) I've only met a handful of *BSD people who know much about it (and they send bug reports or patches). I don't recall if any of them use NetBSD. > I have been informed that NetBSD uses its own curses implementation > which is not "classic" BSD curses and has been created by NetBSD > developers. Not exactly--they started by hacking up BSD curses, and added features. (granted, there's more satisfaction in saying that they redesigned or rewrote it, but that's not the case--rarely is). > But you read that already on tech-userlevel... I'm getting a little > behind in reading and posting and mailing. But I know better now... I read some of it on google--but Google misses a lot of stuff. -- Thomas E. Dickey http://dickey.his.com ftp://dickey.his.com ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.bsd.freebsd.misc References: <3D525097.10874143@SPAMFILTERdavepimlott.info> <20020808204443.38ab4816.steveo@eircom.net> Message-ID: Date: 9 Aug 2002 15:15:00 GMT From: Thomas Dickey Subject: Re: Eterm termcap entry (was Re: TERM) Will Yardley <&-@no.spam.veggiechinese.net> wrote: > Speaking of this (sorta), has anyone had luck getting color with the > "official" Eterm termcap entry? FreeBSD seems to have the "official" > Eterm termcap entry from 0.9.1, but I don't see color when I'm in Eterm > (this is why I usually use xterm-xfree86 as the value of TERM, even > though I'm using Eterm). > If I ssh to a Linux machine that uses terminfo and has the correct Eterm > terminfo file, everything works great. > I remember Thomas explaining the reason for this in the past... > (something having to do with the limitations of termcap itself); > wondering if there is a workaround of any sort. I probably gave a general-purpose answer: termcap entries are generally limited to 1023 bytes. The termcap I made for xterm is a compromise between function-keys and color (gets color and as many function keys will fit). I have a copy of Eterm 0.9 handy, and am looking at its termcap--see two obvious problems (it contains two entries, one is "xterm", the other inherits from that and ansi-pc-color and is called "xterm-color"--but "ansi-pc-color" is not defined there, and the "xterm" entry is too long). Seeing the comment about 0.9.1, I got a copy of that, and see that its termcap only defines "Eterm". In neither case does the termcap entry specify the color capabilities (the terminfo files do though). -- Thomas E. Dickey http://dickey.his.com/ ftp://dickey.his.com/ ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.bsd.freebsd.misc References: <3D525097.10874143@SPAMFILTERdavepimlott.info> <20020808204443.38ab4816.steveo@eircom.net> Message-ID: Organization: Newdream Network Date: Sat, 10 Aug 2002 02:00:01 -0000 From: Will Yardley <&-@no.spam.veggiechinese.net> Subject: Re: Eterm termcap entry (was Re: TERM) In article , Thomas Dickey wrote: > Will Yardley <&-@no.spam.veggiechinese.net> wrote: >> Speaking of this (sorta), has anyone had luck getting color with the >> "official" Eterm termcap entry? FreeBSD seems to have the "official" >> Eterm termcap entry from 0.9.1, but I don't see color when I'm in Eterm >> (this is why I usually use xterm-xfree86 as the value of TERM, even >> though I'm using Eterm). >> If I ssh to a Linux machine that uses terminfo and has the correct Eterm >> terminfo file, everything works great. >> I remember Thomas explaining the reason for this in the past... >> (something having to do with the limitations of termcap itself); >> wondering if there is a workaround of any sort. > I probably gave a general-purpose answer: termcap entries are generally > limited to 1023 bytes. The termcap I made for xterm is a compromise between > function-keys and color (gets color and as many function keys will fit). > > I have a copy of Eterm 0.9 handy, and am looking at its termcap--see > two obvious problems (it contains two entries, one is "xterm", the other > inherits from that and ansi-pc-color and is called "xterm-color"--but > "ansi-pc-color" is not defined there, and the "xterm" entry is too long). > Seeing the comment about 0.9.1, I got a copy of that, and see that its > termcap only defines "Eterm". In neither case does the termcap entry > specify the color capabilities (the terminfo files do though). Hrmm.... The one in the current (stable) FreeBSD release is identical to the one in Eterm9.1 I assumed from the first line that this does specify color capabilities... how would it need to be different? Eterm|Eterm-color|Eterm with xterm-style color support (X Window System):\ :am:bw:eo:km:mi:ms:xn:xo:\ :co#80:it#8:li#24:lm#0:\ :AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:IC=\E[%d@:\ :K1=\E[7~:K2=\EOu:K3=\E[5~:K4=\E[8~:K5=\E[6~:LE=\E[%dD:\ :RI=\E[%dC:UP=\E[%dA:ae=^O:al=\E[L:as=^N:bl=^G:cd=\E[J:\ :ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:cr=^M:\ :cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:do=\E[B:\ :ec=\E[%dX:ei=\E[4l:ho=\E[H:i1=\E[?47l\E>\E[?1l:ic=\E[@:\ :im=\E[4h:is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;3;4;6l\E[4l:\ :k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~:k5=\E[15~:\ :k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:kD=\E[3~:\ :kI=\E[2~:kN=\E[6~:kP=\E[5~:kb=^H:kd=\E[B:ke=:kh=\E[7~:\ :kl=\E[D:kr=\E[C:ks=:ku=\E[A:le=^H:mb=\E[5m:md=\E[1m:\ :me=\E[m\017:mr=\E[7m:nd=\E[C:rc=\E8:\ :sc=\E7:se=\E[27m:sf=^J:so=\E[7m:sr=\EM:st=\EH:ta=^I:\ :te=\E[2J\E[?47l\E8:ti=\E7\E[?47h:ue=\E[24m:up=\E[A:\ :us=\E[4m:vb=\E[?5h\E[?5l:ve=\E[?25h:vi=\E[?25l: ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.bsd.freebsd.misc References: <3D525097.10874143@SPAMFILTERdavepimlott.info> <20020808204443.38ab4816.steveo@eircom.net> Message-ID: Organization: RadixNet Internet Services Date: 10 Aug 2002 18:31:52 GMT From: Thomas Dickey Subject: Re: Eterm termcap entry (was Re: TERM) Will Yardley <&-@no.spam.veggiechinese.net> wrote: > In article , Thomas Dickey wrote: >> termcap only defines "Eterm". In neither case does the termcap entry >> specify the color capabilities (the terminfo files do though). > > Hrmm.... The one in the current (stable) FreeBSD release is identical to > the one in Eterm9.1 > I assumed from the first line that this does specify color > capabilities... how would it need to be different? It must be shortened to make room for something like this (which would make it otherwise about 40 bytes too long): :Co#8:pa#64:AB=\E[4%dm:AF=\E[3%dm:op=\E[39m\E[49m: > Eterm|Eterm-color|Eterm with xterm-style color support (X Window System):\ > :am:bw:eo:km:mi:ms:xn:xo:\ > :co#80:it#8:li#24:lm#0:\ > :AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:IC=\E[%d@:\ > :K1=\E[7~:K2=\EOu:K3=\E[5~:K4=\E[8~:K5=\E[6~:LE=\E[%dD:\ > :RI=\E[%dC:UP=\E[%dA:ae=^O:al=\E[L:as=^N:bl=^G:cd=\E[J:\ > :ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:cr=^M:\ > :cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:do=\E[B:\ > :ec=\E[%dX:ei=\E[4l:ho=\E[H:i1=\E[?47l\E>\E[?1l:ic=\E[@:\ > :im=\E[4h:is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;3;4;6l\E[4l:\ > :k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~:k5=\E[15~:\ > :k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:kD=\E[3~:\ > :kI=\E[2~:kN=\E[6~:kP=\E[5~:kb=^H:kd=\E[B:ke=:kh=\E[7~:\ > :kl=\E[D:kr=\E[C:ks=:ku=\E[A:le=^H:mb=\E[5m:md=\E[1m:\ > :me=\E[m\017:mr=\E[7m:nd=\E[C:rc=\E8:\ > :sc=\E7:se=\E[27m:sf=^J:so=\E[7m:sr=\EM:st=\EH:ta=^I:\ > :te=\E[2J\E[?47l\E8:ti=\E7\E[?47h:ue=\E[24m:up=\E[A:\ > :us=\E[4m:vb=\E[?5h\E[?5l:ve=\E[?25h:vi=\E[?25l: > -- > No copies, please. > To reply privately, simply reply; don't remove anything. -- Thomas E. Dickey http://dickey.his.com/ ftp://dickey.his.com/ ////////////////////////////////////////////////////////////////////////////// Date: 31 Oct 2002 11:27:48 GMT Newsgroups: comp.unix.solaris Message-ID: References: <49d864eb.0210301757.19eb4d20@posting.google.com> From: Thomas Dickey Subject: Re: ncurses on Solaris Quang wrote: > Hello, > I'm developing a character-based UI, and I'd like to use ncurses > instead of the old curses library. ncurses seems to update the > windows/screen and works better. I can statically link my program > against the libncurses.a. However, when it runs on a system without > the termcap entries that comes with ncurses then the program fails to > start when it tries to initialize the screen. > Are there any ways around this? Is it possible to make ncurses look > for /etc/termcap instead of /usr/local/share/.../term/x/xterm... ? It's a configure option (when compiling the ncurses library). However, there are drawbacks: a) ncurses will warn about termcap entries containing strings that don't map into terminfo (a real problem given the poor quality of the termcap files distributed as such). b) the translated termcap can be cached in $HOME/.terminfo, but that's a nuisance for several reasons Using terminfo is preferred--or compiled-in fallback entries if it has to be self-contained. -- Thomas E. Dickey ////////////////////////////////////////////////////////////////////////////// Date: 31 Oct 2002 14:34:21 -0800 Organization: http://groups.google.com/ Newsgroups: comp.unix.solaris Message-ID: <49d864eb.0210311434.6f321e79@posting.google.com> References: <49d864eb.0210301757.19eb4d20@posting.google.com> From: Quang Subject: Re: ncurses on Solaris Thomas Dickey wrote in message news:... > Using terminfo is preferred--or compiled-in fallback entries if it has > to be self-contained. Thanks for your response. Could you please explain the compiled-in fallback entries. I'm not sure how to archive this or how you mean it. Thanks, Quang ////////////////////////////////////////////////////////////////////////////// Date: 1 Nov 2002 01:28:07 GMT Newsgroups: comp.unix.solaris Message-ID: References: <49d864eb.0210301757.19eb4d20@posting.google.com> <49d864eb.0210311434.6f321e79@posting.google.com> From: Thomas Dickey Subject: Re: ncurses on Solaris Quang wrote: > Thanks for your reponse. Could you please explain the compiled-in > fallback entries. I'm not sure how to archive this or how you mean it? It's listed in the INSTALL file in the sources. For example (omitting other options for clarity): configure --with-fallbacks=vt100,xterm make compiles in data (assuming infocmp is ncurses', since it uses options from that for generating source) from the terminfo database which is used if an ncurses application cannot later find those in the database. -- Thomas E. Dickey ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals References: <3e5f2986$0$234$626a54ce@news.free.fr> Message-ID: Date: 28 Feb 2003 12:48:42 GMT From: Thomas Dickey Subject: Re: ncurses and Win "Hervé" wrote: > Does anyone know if there is a ncurses library for Win32 ? using cygwin, yes. otherwise pdcurses is close enough to port many applications. however, most of the games I've seen weren't written with portability in mind. > I'd like to compile my ncurses unix-games under Windows, and the curses and > ncurses library are the only problems I encounter. (All other code parts are > ANSI compliant and can be compiled without any problem...) > Thanks. > Herve (delete _nospam in email address) > PS: sorry, it's not exactly the subject of this group, but there is no > comp.terminals.programming, so perhaps finally I'm in the good NG??? -- Thomas E. Dickey ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals References: Message-ID: Date: 28 Feb 2003 12:50:28 GMT From: Thomas Dickey Subject: Re: ncurses and terminal Matthias Pieroth wrote: > Hi NG, > I'm writing a c++ application to display some text with ncurses. I have some > problems: > 1. How can I change my terminal to can_change_colors? The function returns > false. it depends on the terminal type ($TERM should match the terminal's capabilities). linux console can--though I notice Redhat (mis)applies a patch to disable it. > 2. I have a text over 80x25 chars. I want to run my program in a konsole but > the 80x25 chars should fill the whole screen. How can this be done? Change > the resolution? How? > 3. The blink of ncurses doesn't work in konsole-modus (Ctrl,ALT + F2). In a > normal terminal it works. As far as I know, konsole doesn't support blinking text -- most terminal emulators in X do not. -- Thomas E. Dickey ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals References: Message-ID: Date: 28 Feb 2003 15:07:51 GMT From: Thomas Dickey Subject: Re: ncurses and terminal Matthias Pieroth wrote: > Hi, > about colors: In the ncurses.h there are only 8 color-constants. I heard > that ncurses can use 16 colors. How? those are predefined constants--colors with standard assignments/names. a few terminals (with corresponding terminal descriptions) allow you to set color codes 8-15. See the discussion of init_pair in the manpage: COLOR_PAIRS is set from the terminal description, and would be 16 in this case. -- Thomas E. Dickey ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.programmer Message-ID: Date: Tue, 08 Apr 2003 18:26:57 +0200 From: Michael Steinbauer Subject: ncurses 'field' in string umwandeln. Hi, ich habe die Doku rauf und runter gelesen und komm nicht dahinter. Ich moechte von ncurses die field und forms Funktionen nutzen. Geht auch wunderbar, die Eingaben erfolgen dann in ein Feld, welches so FIELD *field[1] definiert wurde. Mein Problem. Wie bitte komme ich jetzt zu dem String, der in *field[1] drinnen steht. Alle strcpy Versuche scheitern natuerlich, weil field ja kein String ist. Ich hoffe ich komm aus der Gedanken Sackgasse wieder raus... Michael ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.programmer Message-ID: References: Date: Wed, 9 Apr 2003 00:33:46 GMT From: Thomas Dickey Subject: Re: ncurses 'field' to string transfer. Michael Steinbauer wrote: > Hi, > I couldn't find an answer in my docu files, so I try it here... > > I'm using ncurses with the functions field and forms. It works great, > but after I filled a 'field' which is defined as FIELD *field[1], on > screen, the typed-in letters are stored in field[1]. > > Now I need the string, which was typed in 'field[1]'. strcpy doesn't > work, cause field[1] isn't a string. field_buffer() might be useful. I added a sample program cardfile.c to ncurses a while ago that uses this. -- Thomas E. Dickey http://dickey.his.com/ ftp://dickey.his.com/ ////////////////////////////////////////////////////////////////////////////// Newsgroups: alt.folklore.computers Message-ID: <1716.235T2368T12505901@kltpzyxm.invalid> References: <1825.230T1674T5474619@kltpzyxm.invalid> <3E95BE41.8F39F3B8@yahoo.com> <3E99D6FD.92831B5F@yahoo.com> Organization: http://extra.newsguy.com Date: 15 Apr 03 20:50:47 -0800 From: Charlie Gibbs Subject: Re: Any DEC 340 Display System Doco ? In article shannon@news.widomaker.com (Charles Shannon Hendrix) writes: >In article <3E99D6FD.92831B5F@yahoo.com>, CBFalconer wrote: > >>> Or as I did in a small program just a few months ago: >>> - hold two screen images in memory (current and new), >>> - init both to the same state, push current to real display, >>> - generate new screen image in new, compare current and new, >>> - send only the diffs to the real display, >>> - set current = new, > >This is a great way to do graphics even if you don't push only diffs. > >What I'd like to see is a good way of doing this with curses >applications. Some curses libraries are supposed to do that >automatically though. I thought that such optimization was one of curses' reasons for living. In fact, there's a touchwin() function that's specifically designed to force a complete screen redraw without any optimization. Quoting the curs_touch man page on my Linux box: The touchwin and touchline routines throw away all optimization information about which parts of the window have been touched, by pretending that the entire window has been drawn on. This is sometimes necessary when using overlapping windows, since a change to one window affects the other window, but the records of which lines have been changed in the other window do not reflect the change. Yes, I use curses a lot, and I've recently had occasion to use touchwin()... -- /~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs) \ / I'm really at ac.dekanfrus if you read it the right way. X Top-posted messages will probably be ignored. See RFC1855. / \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign! ////////////////////////////////////////////////////////////////////////////// Newsgroups: alt.folklore.computers, alt.sys.pdp10 Message-ID: References: <3e8ae086.45754328@news.m.iinet.net.au> <3E99D6FD.92831B5F@yahoo.com> Organization: TSS Inc. Date: 16 Apr 2003 12:16:08 GMT From: Peter da Silva Subject: Re: Any DEC 340 Display System Doco ? In article , Charles Shannon Hendrix wrote: > >What I'd like to see is a good way of doing this with curses >applications. Some curses libraries are supposed to do that >automatically though. Some? The whole point to curses in the first place was optimising screen updates by only sending diffs. If you just wanted terminal independence you used the underlying termcap library. -- Rev. Peter da Silva, ULC. 29.6852N 95.5770W WWFD? ////////////////////////////////////////////////////////////////////////////// Date: Tue, 24 Jun 2003 18:44:12 -0400 To: Mac-Users From: Greg L. Subject: MacHack keynote This year the MacHack keynote speaker was Ken Arnold, a member of the BSD team at the University of California at Berkeley who developed the "curses" library. At Sun Microsystems, Ken was an original architect of the Jini platform." http://www.macfixit.com/article.php?story=20030621115125746 ////////////////////////////////////////////////////////////////////////////// Solaris curses (SVR4 type) examines these four environment variables: TERM TERMINFO LINES COLUMNS ...RSS ////////////////////////////////////////////////////////////////////////////// A notable problem with one of the "curses" functions in Solaris (bug 4360114 in "tcsetattr") was revealed by Sun in early A.D. 2004. While data security as such is not necessarily at risk, exploitation by an unprivileged local user can lead to a denial of service through a hung system: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F57474 The problem can occur only on a SPARC processor running the following releases: Solaris 2.6 without patch 105924-12 Solaris 7 without patch 107589-06 Solaris 8 without patch 109815-20 Prudent system administrators should install the appropriate patch or upgrade to Solaris 9 or later. ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals NNTP-Posting-Host: saltmine.radix.net References: Message-ID: Date: 24 Aug 2003 22:18:51 GMT From: Thomas Dickey Subject: Re: ncurses and key-modifiers Simon Strandgaard <0bz63fz3m1qt3001@sneakemail.com> wrote: >> xterm -v > XFree86 4.3.99.5(179) >> > Still define_key() doesn't seem to have any effect ? > SHIFT|KEY_UP should yield the escape sequence "\eO2A", > With this code, pressing SHIFT|KEY_UP should result in > "ok = 0, key = 42", But nothing happens. > Do you have a better example of usage of define_key ??? I wrote an example for it, which is in ncurses' test directory (demo_defkey.c). That's in post-5.3 changes (last December), so you'd need the rollup patch at ftp://invisible-island.net/ncurses/5.3/ to see this. -- Thomas E. Dickey http://dickey.his.com/ ftp://dickey.his.com/ ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.solaris NNTP-Posting-Host: saltmine.radix.net References: Message-ID: Date: 9 Nov 2003 01:50:46 GMT From: Thomas Dickey Subject: Re: Setting 132 columns in Solaris Joerg Schilling wrote: > > This contradicts your previous writings! > So you either did not understand what I was writing or you are unwilling > to do so :-( I understood your posting. It was quite ignorant to start in a Solaris thread asserting that you're using termcap. Do you use Solaris, or are you just fond of typing? (Apparently the latter). ldd shows (read the manpage): /usr/bin/vi: libmapmalloc.so.1 => /usr/lib/libmapmalloc.so.1 libcurses.so.1 => /usr/lib/libcurses.so.1 libcrypt_i.so.1 => /usr/lib/libcrypt_i.so.1 libgen.so.1 => /usr/lib/libgen.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 /usr/platform/SUNW,Ultra-60/lib/libc_psr.so.1 strings (on libcurses) shows TERM TERMINFO /usr/share/lib/terminfo/ (don't waste my time if you choose to be ignorant) -- Thomas E. Dickey ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Message-ID: <3fbc8b9c$0$27051$626a54ce@news.free.fr> Organization: Guest of ProXad--France Date: 20 Nov 2003 09:38:38 GMT From: Thomas Baruchel Subject: Using terminfo (curses) Hi, I write a C code, providing a shell. readline provides the interface, but I also use ncurses, without intializing the curses, in order to access the terminfo database. Is that the right way ? I would like to know what is the best protocol in order to get the string sequence for BOLD+COLOR. I use "md" key for bold, and think it is fully portable. Now, I would like one color; onyl one, because it is only in order to make some informations quite visible in the output; red id wanted, but what is even more wanted is portability. Should I perform a test in order to know if there are colors ? If yes, how ? Then, what is the cleanest way to get the string sequence, with the highest probability to get red (or blue or magenta), but not these colors that are difficult to read with some white background in an xterm (cyan, green)? If you think I will lose in portability, I like rather only use bold than trying to also get the colors. -- « nous devons agir comme si la chose qui peut-être ne sera pas devait être » (Kant, Métaphysique des moeurs, doctrine du droit, II conclusion) Thomas Baruchel .............................................................................. Newsgroups: comp.terminals Message-ID: References: <3fbc8b9c$0$27051$626a54ce@news.free.fr> Organization: Guest of ProXad--France Date: Thu, 20 Nov 2003 14:58:06 +0100 From: Stephane CHAZELAS Subject: Re: Using terminfo (curses) On 2003/11/20, 09:38(+00), Thomas Baruchel wrote: > > I write a C code, providing a shell. readline provides the interface, > but I also use ncurses, without intializing the curses, in order to > access the terminfo database. Is that the right way ? Anyway, readline uses ncurses. See curs_terminfo(3) for how to use terminfo ncurses functions. > I would like to know what is the best protocol in order to > get the string sequence for BOLD+COLOR. > > I use "md" key for bold, and think it is fully portable. "md" is termcap, not terminfo. terminfo equivalent is "bold". > Now, I would like one color; onyl one, because it is only in > order to make some informations quite visible in the output; > red id wanted, but what is even more wanted is portability. Nothing really fully portable in that area. The simpler is probably to limit to ANSI 8 color support, and drop the color support for terminals that support color support but not in the ansi way, since they are quite uncommon now. Some terminals allow to edefine color pairs (bg+fg), and to select one. Some terminals have support for 8, 16, 88, 256 colors (XFree86 xterm is able to support all of them at the same time and to redefine colors through escape sequences, but compile time options must be set). Note that the terminfo databases are often not correct. For instance, systems with XFree86 xterm often use "xterm" or "xterm-color" for $TERM while XFree86 xterm has at least 16 color support (not 8), (I think "xterm" are generic entries that apply /mostly/ to several flavours of "xterm"). > Should I perform a test in order to know if there are colors ? > If yes, how ? Look at "colors" and "pairs" cababilities, then look wether there are setaf/setab terminfo capabilities (ANSI colors then) failing that "setf/setb" (maybe not ANSI colors), failing that "initp/scp" for color pair mode (see HP terminals for instance). > Then, what is the cleanest way to get the string sequence, > with the highest probability to get red (or blue or magenta), You can assume the 8 first ANSI colors are the default ones. That's what's generaly done in curses applications. color "1" is fg-red, 2, green, 3 yellow... You can't really assume which red, which green they are... Some terminals use a different color in normal and in bold mode. If the terminal supports color-pairs, you can define them as the default ANSI colors (with a single background). tput initc 1 1000 0 0 1000 1000 1000 #defines color 1 to red on white > but not these colors that are difficult to read with some > white background in an xterm (cyan, green)? I'd say that it's up to the user (or system or terminal developper) to ensure every color is legible on the default background. That's theory... With a black background, there are fewer legibility problems, but you'll have to be carefull at "bce" if you don't use the default background color. For more complete support, you could play with "initc", "initp", test for "xterm" or "rxvt" (those terminals may be queried for their "identifier", some may even be queried for termcap entries). For instance, in an XFree86 xterm with 256color support, you can do (shell syntax) printf %b '\e]10;#FFFFFF;#000000\a\e]4;1;#FF0000\e\\' # To define white on black and bright red as color 1. echo "This is white on black" printf '%b%s\n' '\e[31m' 'This is red on black' color 1 can be defined as tput 1 1000 0 0 but I don't think there's a terminfo way to define the default background or foreground. (tput setaf 1 to select ANSI color 1). > If you think I will lose in portability, I like rather only > use bold than trying to also get the colors. You could use a config variable or an option to activate ANSI color support and use explicit '\e[3m' sequences without even bother with terminfo, that's what some applications do (see elinks, info -f zsh --index-search=colors) -- Stéphane ["Stephane.Chazelas" at "free.fr"] .............................................................................. Newsgroups: comp.terminals Message-ID: References: <3fbc8b9c$0$27051$626a54ce@news.free.fr> Organization: Guest of ProXad--France Date: Thu, 20 Nov 2003 15:04:40 +0100 From: Stephane CHAZELAS Subject: Re: Using terminfo (curses) 2003/11/20, 14:58(+01), Stephane CHAZELAS: [...] > If the terminal supports color-pairs, you can define them as the > default ANSI colors (with a single background). > > tput initc 1 1000 0 0 1000 1000 1000 initp initc also exists but it defines a color, not a color pair (so doesn't apply for terminals that use color pairs). See terminfo(5), and the ctlseqs.ms file in XFree86 xterm source tarball (ftp://invisible-island.net/xterm/), (you find such a document in rxvt sources too). -- Stéphane ["Stephane.Chazelas" at "free.fr"] .............................................................................. Newsgroups: comp.terminals Message-ID: References: <3fbc8b9c$0$27051$626a54ce@news.free.fr> Date: 20 Nov 2003 14:58:19 GMT From: Thomas Dickey Subject: Re: Using terminfo (curses) Stephane CHAZELAS wrote: > 2003/11/20, 09:38(+00), Thomas Baruchel: >> I write a C code, providing a shell. readline provides the interface, >> but I also use ncurses, without intializing the curses, in order to >> access the terminfo database. Is that the right way ? > Anyway, readline uses ncurses. actually readline uses termcap--provided by ncurses or other libraries. >> Should I perform a test in order to know if there are colors ? >> If yes, how ? > Look at "colors" and "pairs" cababilities, then Also pay attention to ncv. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net .............................................................................. Newsgroups: comp.terminals Message-ID: References: <3fbc8b9c$0$27051$626a54ce@news.free.fr> Organization: Guest of ProXad--France Date: Thu, 20 Nov 2003 17:26:49 +0100 From: Stephane CHAZELAS Subject: Re: Using terminfo (curses) On 2003/11/20, 14:58(+00), Thomas Dickey wrote: [...] > >> Anyway, readline uses ncurses. > > actually readline uses termcap--provided by ncurses or other libraries. Maybe Thomas should use termcap then for wider portability. My experience is that termcap databases are generally even less accurate than terminfo ones (not to speak of the fact that termcap capabilities allow fewer things than terminfo), but for only 8 ANSI color support, that should be enough (check for Co and AF) But no doubt you have a greater experience on this. >>> Should I perform a test in order to know if there are colors ? >>> If yes, how ? > >> Look at "colors" and "pairs" cababilities, then > > also pay attention to ncv. Thanks to point this out. From ncurses terminfo(5): M| On some color terminals, colors collide with highlights. You can reg- M| ister these collisions with the ncv capability. This is a bit-mask of M| attributes not to be used when colors are enabled. The correspondence M| with the attributes understood by curses is as follows: M| M| M| Attribute Bit Decimal M| A_STANDOUT 0 1 M| A_UNDERLINE 1 2 M| A_REVERSE 2 4 M| A_BLINK 3 8 M| A_DIM 4 16 M| A_BOLD 5 32 M| A_INVIS 6 64 M| A_PROTECT 7 128 M| A_ALTCHARSET 8 256 M| M| For example, on many IBM PC consoles, the underline attribute collides M| with the foreground color blue and is not available in color mode. M| These should have an ncv capability of 2. M| M| SVr4 curses does nothing with ncv, ncurses recognizes it and optimizes M| the output in favor of colors. But: ~$ infocmp -1 xterm-256color | grep ncv ncv#32, That would mean that colors colide with bold mode. I guess it refers to the fact that when boldColors resource is on, you get different colors for bold mode for ANSI colors. But I don't think it applies to xterm-256color With "XTerm*boldColor: on", in: TERM=xterm-256color sh -c 'tput setaf 1; echo AAA; tput bold; echo BBB' AAA and BBB are of the same color not with: TERM=xterm-16color sh -c 'tput setaf 1; echo AAA; tput bold; echo BBB' TERM=xterm-xfree86 sh -c 'tput setaf 1; echo AAA; tput bold; echo BBB' (ncv is not defined in my "xterm-xfree86" entry, though). (ncurses 5.3, xterm 180) Are color RGB values standardized in any way, or is it just 0 = black, 1 = red ... and colors after 8 are just brighter versions of the same ones (or something else)? -- Stéphane ["Stephane.Chazelas" at "free.fr"] .............................................................................. Newsgroups: comp.terminals Message-ID: References: <3fbc8b9c$0$27051$626a54ce@news.free.fr> Date: 21 Nov 2003 12:00:31 GMT From: Thomas Dickey Subject: Re: Using terminfo (curses) Stephane CHAZELAS wrote: > 2003/11/20, 14:58(+00), Thomas Dickey: > [...] >>> Anyway, readline uses ncurses. >> >> actually readline uses termcap--provided by ncurses or other libraries. > Maybe Thomas should use termcap then for wider portability. My > experience is that termcap databases are generally even less > accurate than terminfo ones (not to speak of the fact that > termcap capabilities allow fewer things than terminfo), but for > only 8 ANSI color support, that should be enough (check for Co > and AF) yes--but I would make a distinction between the termcap database and the termcap interface. The latter is emulated on top of terminfo in ncurses and most vendor's Unixes. When it is emulated in this fashion, the data that is returned to the application is actually terminfo rather than termcap--but a portable application would not look closely enough to be affected. > ~$ infocmp -1 xterm-256color | grep ncv > ncv#32, > That would mean that colors colide with bold mode. I guess it > refers to the fact that when boldColors resource is on, you get > different colors for bold mode for ANSI colors. But I don't > think it applies to xterm-256color not exactly. It means that the bold attribute doesn't work with colors. You may get a different color, or even no effect at all. (Now I suppose I should investigate making bold attribute work properly for 256-colors). > With "XTerm*boldColor: on", in: > TERM=xterm-256color sh -c 'tput setaf 1; echo AAA; tput bold; echo BBB' > AAA and BBB are of the same color > not with: > TERM=xterm-16color sh -c 'tput setaf 1; echo AAA; tput bold; echo BBB' > TERM=xterm-xfree86 sh -c 'tput setaf 1; echo AAA; tput bold; echo BBB' > (ncv is not defined in my "xterm-xfree86" entry, though). I'd expect some differences with setaf 10 or setaf 20, though. > (ncurses 5.3, xterm 180) > Are color RGB values standardized in any way, or is it just 0 = > black, 1 = red ... and colors after 8 are just brighter versions > of the same ones (or something else)? I suppose there must be a standard someplace, but I've not encountered it. When I set up the 16-color resources for xterm some time ago, I simply used the most visible ones that I could find in rgb.txt -- but as noted frequently, the blue doesn't show well against a black background. (a related question would be if the names in rgb.txt are standardized - referring to a standard outside X--I suspect the answer is no). -- Thomas E. Dickey http://invisible-island.net/ ftp://invisible-island.net/ ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals, comp.unix.programmer NNTP-Posting-Host: 88ba7a12.news.jtan.com References: Message-ID: <49b6fdc7$0$21577$e4f62565@news.jtan.com> Organization: Jtan (jtan.com) Date: 10 Mar 2009 23:54:47 GMT From: Thomas E. Dickey Subject: Re: tput: why does setb and setf not work, but setab and setaf do? In comp.terminals Stephane CHAZELAS wrote: > > So basically, I'd expect a given terminal to support either one > or the other, or then the 2 sets to give different results. Right - but early on, someone created terminal descriptions with setf/setb which are used in a lot of places (and are assumed to be _only_ setf/setb by relatively stagnant applications such as emacs ;-) > Check the output of "infocmp" to see what's supported on your > terminal > > $ TERM=xterm infocmp -1 | grep -E 'seta?[bf]' > setab=\E[4%p1%dm, > setaf=\E[3%p1%dm, > setb=\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m, > setf=\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m, > $ TERM=rxvt infocmp -1 | grep -E 'seta?[bf]' > setab=\E[4%p1%dm, > setaf=\E[3%p1%dm, > > The xterm one seems to shuffle the values around (it seems to > swap 1 <-> 4 and 3 <-> 6), not sure one. So for setf/setb, color > 1 must be blue instead of red, not sure where to look for for > the /specification/ A partial answer: http://invisible-island.net/ncurses/ncurses.faq.html#interchanged_colors -- Thomas E. Dickey http://invisible-island.net/ ftp://invisible-island.net/ ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Message-ID: <11b8ud08h2hsua3@corp.supernews.com> References: Date: Sat, 18 Jun 2005 19:44:32 -0000 From: Thomas Dickey Subject: Re: Bold attribute not working with xterm-256color Morten Bo Johansen wrote: > Hi, > > I am using a Ubuntu Linux system with these programs installed > > - xterm 6.8.2-10 (XTerm(197)) > - ncurses-base, ncurses-bin, ncurses-term 5.4-4 (20040320) > > and with TERM=xterm-256color the bold attribute is not working > for things such as directory listings in mc and unread messages > in slrn (they show as normal "unbold" characters instead). The ncv#32 says it doesn't combine bold with color. I removed that from the entry in May 2004 after someone pointed it out--can't recall if it was at one time needed. Removing that piece should make it work. > # Reconstructed via infocmp from file: /home/mojo/.terminfo/x/xterm-256color > xterm-256color|xterm with 256 colors, > am, bce, ccc, km, mc5i, mir, msgr, npc, xenl, > colors#256, cols#80, it#8, lines#24, ncv#32, pairs#256, ^^^^^^ -- Thomas E. Dickey http://invisible-island.net/ ftp://invisible-island.net/ ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.solaris NNTP-Posting-Host: 24.132.47.86 NNTP-Posting-Date: 01 Dec 2003 10:32:24 CET References: <122c561c.0311300656.36225100@posting.google.com> Message-ID: <3fcb0aa8$0$1505$e4fe514c@news.xs4all.nl> Organization: Sun Microsystems, Netherlands Date: 01 Dec 2003 09:32:24 GMT From: Casper H.S. Dik Subject: Re: curses mouse cut/paste on solaris2.9, hangs on select(). Works fine on aix and linux ajay.rathaur@wipro.com (Ajay) writes: > > I am facing problem with a curses program which does not work on Solaris 9. > If the user inputs a strings using mouse. The string is not visible on > the window and it hangs on the select() system call > The program works fine on solaris, if the user inputs the string from > the keyboard. This looks like a typical problem caused by mixing some buffered input (wgetch) and something which looks at the underlying file descriptor (select). What you probably need to do is recode the routine which gets input to: - make input non-blocking - read with wgetch() until ERR - and only then select() if you need more. Casper -- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth. ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.programmer, comp.terminals Message-ID: Organization: EarthLink Inc. -- http://www.EarthLink.net Date: Sun, 23 May 2004 00:26:53 GMT From: Kevin L Subject: Terminfo: how to interrogate without changing MY term? Hi all, I have a need to interrogate the local terminfo database for a terminal that is NOT my application's current terminal. My app loads up in a Linux console window, so it fires up and curses initializes to the "TERM=linux" entry. But my app talks VT102 to another system, and I'd like to ask curses what a particular VT102 keystroke maps to so I can send that string to the remote host when the user presses a key I haven't handled already (e.g. function key F5 -- doesn't exist on a real VT102 but lots of host-side apps will pretend "\EOt" is F5). What I need is the ability to pass in "kf5" to some function and get "\EOt" back, just like 'infocmp -E vt102' can do. I could just paste my local terminfo's infocomp output into a header and use that, but I'd really prefer a dynamic solution. I've been perusing the ncurses source and I see how I could do it under the hood, but is there a supported way to do this already I'm not seeing? Finally, would any method work for both ncurses and SVr4 curses? .............................................................................. Newsgroups: comp.unix.programmer, comp.terminals References: Message-ID: Organization: Looking for work Date: Sat, 22 May 2004 21:02:36 -0400 From: Barry Margolin Subject: Re: Terminfo: how to interrogate without changing MY term? In article , Kevin L wrote: > > I have a need to interrogate the local terminfo database for a > terminal that is NOT my application's current terminal. You can use curses to manage a terminal other than your controlling terminal by using newterm() instead of initscr(). This takes the terminal type as a parameter. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA .............................................................................. Newsgroups: comp.unix.programmer, comp.terminals References: Message-ID: <10avver44c2t52d@corp.supernews.com> Date: Sun, 23 May 2004 01:26:51 -0000 From: Thomas Dickey Subject: Re: Terminfo: how to interrogate without changing MY term? In comp.terminals Kevin L wrote: > > ...But my app talks VT102 to another system, and I'd > like to ask curses what a particular VT102 keystroke maps to so I can > send that string to the remote host when the user presses a key > I haven't handled already (e.g., function key F5--doesn't exist on a > real VT102 but lots of host-side apps will pretend "\EOt" is F5). > What I need is the ability to pass in "kf5" to some function and get > "\EOt" back, just like 'infocmp -E vt102' can do. % man tgetent % man tigetstr See the ncurses source test/railroad.c for a simple application using only terminfo to test features. > Finally, would any method work for both ncurses and SVr4 curses? This would (but see the note at the end of ncurses' tgetent manpage). -- Thomas E. Dickey http://invisible-island.net/ ftp://invisible-island.net/ .............................................................................. Newsgroups: comp.unix.programmer, comp.terminals References: <10avver44c2t52d@corp.supernews.com> Message-ID: Organization: EarthLink Inc. -- http://www.EarthLink.net Date: Sun, 23 May 2004 03:06:16 GMT From: Kevin L Subject: Re: Terminfo: how to interrogate without changing MY term? Thomas Dickey wrote: > > % man tgetent > % man tigetstr > See the ncurses source test/railroad.c for a simple application using > only terminfo to test features. > > >Finally, would any method work for both ncurses and SVr4 curses? > > this would (but see the note at the end of ncurses' tgetent manpage). Thank you! Combining this with what Mr Margolin said, will this work? /* Before my original call to initscr() */ FILE * my_null = fopen("/dev/null", "r+"); SCREEN * my_vt102 = newterm("vt102", my_null, my_null); SCREEN * my_real_term = set_term(my_vt102); char * vt102_kf1 = tigetstr("kf1"); char * vt102_kf2 = tigetstr("kf2"); ... set_term(my_real_term); delscreen(my_vt102); fclose(my_null); /* My original call to initscr(), after which all is easy-to-follow curses calls... */ initscr(); ? .............................................................................. Newsgroups: comp.unix.programmer, comp.terminals References: <10avver44c2t52d@corp.supernews.com> Message-ID: <10b62jpgu43ns53@corp.supernews.com> Date: Tue, 25 May 2004 08:57:29 -0000 From: Thomas Dickey Subject: Re: Terminfo: how to interrogate without changing MY term? In comp.terminals Thomas Dickey wrote: | | See the ncurses source test/railroad.c for a simple application using | only terminfo to test features. I should have said dots.c (railroad.c is termcap). In comp.terminals Kevin L wrote: > > Thank you! Combining this with what Mr Margolin said, will this work? > > /* Before my original call to initscr() */ > FILE * my_null = fopen("/dev/null", "r+"); > SCREEN * my_vt102 = newterm("vt102", my_null, my_null); > SCREEN * my_real_term = set_term(my_vt102); > char * vt102_kf1 = tigetstr("kf1"); > char * vt102_kf2 = tigetstr("kf2"); > ... > set_term(my_real_term); > delscreen(my_vt102); > fclose(my_null); Opening /dev/null looks odd: it's not really needed for getting data from terminfo, and I wouldn't expect it to act like a tty. But I guess it would work for this case (since no I/O is actually done). For testing portability, I suppose it would be best to test the platforms, since they're different in subtle ways. -- Thomas E. Dickey http://invisible-island.net/ ftp://invisible-island.net/ ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Message-ID: <35050f5c.0406011602.34071e6c@posting.google.com> Date: 1 Jun 2004 17:02:50 -0700 From: twisteddweeb@yahoo.com Subject: Best method to recognize Escape vs Escape-Seq in a unix program A n00b question, I know, but I can't get an answer from google just yet. What is the preferred method for parsing a bare ESC vs an ESC-seq in a unix program? Eg. in xterm I want to be able to tell if the escape key has been pressed (like in vi) vs the F1 key. At first I thought that I'd just use (the equivalent of) tcsetattr() and set the MIN and TIME to "appropriate" values. But the more I thought about it the more problems I can envision with this method. What if the program is used remotely? what is you pipe data into the program vs. human input? etc. Now I'm considering a FSM for them but I haven't done an analysis of terminfo to see what kinds of problems there could be there just yet. Maybe there are sequences that collide? I dunno... Any ideas or links would be appreciated. Yes, I'll be looking at the source of xterm, rxvt, bash, vim, readline(?) etc., but I wanted to just plain ask the question too to see what the experts say as well. There are likely many nuances I won't be able to pick up from the sources alone. .............................................................................. Newsgroups: comp.terminals References: <35050f5c.0406011602.34071e6c@posting.google.com> Message-ID: <40BD4146.5020900@nyc.rr.com> Date: Wed, 02 Jun 2004 02:54:00 GMT X-From: From: Jeffrey Altman Subject: Re: Best method to recognize Escape vs Escape-Seq in a unix program Professional opinion. Do not treat the ESC key as a key. It is not. The ESC key on Unix or any terminal is present so that users may manually enter escape sequences. To try to treat it as anything else is only going to cause your users and support staff major headaches. Jeffrey Altman .............................................................................. Newsgroups: comp.terminals, comp.unix.programmer References: <35050f5c.0406011602.34071e6c@posting.google.com> Message-ID: Organization: The Late, Great Stratagy Users Group Date: Tue, 1 Jun 2004 23:57:50 -0400 From: Richard S. Shuford Subject: Re: Best method to recognize Escape vs Escape-Seq in a unix program twisteddweeb@yahoo.com wrote: > > A n00b question, I know, but I can't get an answer from google just > yet. At one time, this subject matter was something of a FAQ, although it has appeared less frequently as of late. However, one treatment is still visible on the net: http://ftp.digital.com/pub/Digital/termcaps/faqvt525.txt 6. Why don't the arrow keys work with 'vi' in VT modes? ANSI arrow keys transmit key sequences which have the form up arrow = Esc [ A 'vi' has two modes of operation: Command mode and Insert mode. 'vi' interprets the ASCII Escape code as a command to exit Insert Mode and return to Command mode. If an Escape is received while in Command mode, it is an error and the user is notified by beeping the terminal. When 'vi' receives an Escape code it starts a timer. If the timer times out before receiving the "[" code, 'vi' interprets the Escape as an Escape and the following "[ A" codes are interpreted as commands. These "bad commands" cause 'vi' to beep the terminal. The symptom is intermittent as it is timing dependent and is effected by communications channel delays and processor speeds. Workaround: Enter the 'vi' command, "set notimeout". You can find some related discussion here: http://www.cs.utk.edu/~shuford/terminal_index.html ...RSS .............................................................................. Newsgroups: comp.terminals References: <35050f5c.0406011602.34071e6c@posting.google.com> Message-ID: <_%kvc.35421$zO3.4532@newsread2.news.atl.earthlink.net> Date: Wed, 02 Jun 2004 13:56:10 GMT From: Kevin L Subject: Re: Best method to recognize Escape vs Escape-Seq in a unix program twisteddweeb@yahoo.com wrote: > > A n00b question, I know, but I can't get an answer from google just > yet. The easiest way I think would be to just rely on ncurses to do this for you. Calling keypad(stdscr, TRUE) after initscr() and using getch() (or wgetch()) instead of getchar() will result in the behavior you're probably seeking: 1) ESC typed by itself will return 0x1B to getch() after about 1 second. So users can use ESC as a real key, even though you'll find lots of reasons they shouldn't. For my project (cloning an old MS-DOS program that has entered legal limbo) I support ESC because the original program used it, but I also encourage use of the backtick (`) key since on most PC101/104 keyboards backtick is in almost the same position, and it's a trivial habit to change. 2) Arrow keys, function keys, page-up/down, etc. will return the appropriate KEY_LEFT, KEY_F(4), codes etc. immediately. Ncurses does all the parsing so [D become KEY_LEFT in vt100-ish emulations. More importantly, when someone uses my program on another kind of terminal it will usually work right out of the box (knock on wood) because ncurses will use the terminfo database to do it all for me. And ncurses seems to work well regardless of the plumbing between my program and the user. I've run my program inside itself and arrow keys still work fine, and the path is: console -> my program -> pipe -> /dev/ptyXX <==> /dev/ttyXX -> pipe -> bash shell -> my program. Lots of layers and even two separate emulations involved, yet ncurses does it all quite smoothly. Finally, remember that ALT- or META- on most unix-y terminals results in two keystrokes: ESC followed by the character. Ncurses passes this case to me exactly as I expect it to: as the two keystrokes 0x1B followed by the character. If you'd like to dig through my source, it's at http://sourceforge.net/projects/qodem If the CVS link is still broken, you can download qodem 0.0.6 and look at the ncurses setup around qodem.c:800, the global keyboard reader routine around states.c:50, and console_keyboard_handler() in console.c to see how those keys get seen by my program. The only unusual thing I do is process the ALT- into a global ALT flag before calling a X_keyboard_handler(). .............................................................................. Newsgroups: comp.terminals References: <35050f5c.0406011602.34071e6c@posting.google.com> <_%kvc.35421$zO3.4532@newsread2.news.atl.earthlink.net> Message-ID: <35050f5c.0406030622.49ef401@posting.google.com> Date: 3 Jun 2004 07:22:28 -0700 From: twisteddweeb@yahoo.com Subject: Re: Best method to recognize Escape vs Escape-Seq in a unix program Thank you Jeffrey, Richard, & Kevin I knew this had to have been a FAQ but I couldn't find the incantation to google. Too much "programming" and not enough "vi" in the google I guess. Now I *KNOW* why the Esc key shouldn't be used as a bare modifier, too much thought is being wasted on this simple detail. I particularly like the backtick idea because I can reach it w/o leaving home row. IMHO, I like hitting keys in sequence, chords make me move my hands all around so much that I might as well be using the mouse. Either use the mouse or don't I hate in between. I am a bit stubborn about these kinds of things so I won't be satisfied until I can come up with an elegant solution to this pesky detail... I know it's too much effort for a detail that should not be there to begin with but it's already there and, hey, look at my handle :D As far as I can make out from the FAQ vi does both; if the timer fails then go to a finite state machine. I really haven't gone too far into the code yet to verify my guess. Xterm, on the other hand, is doing a fsm(?) but I have only started to look at that code. Ncurses, normally I would just use that (and in the past i have found it most useful) but for this project I just wanted to use the kernel as a sort of bios and avoid libs. No, I have no religious prohibition against libs it's just my way of boot strapping my knowledge base. In my experience, ncurses is rock solid so there is no reason I can't learn from that source. That one pops to the top of the source reading list. Thanks again all PS: Oh yea, I've just migrated to NetBSD (for now) and the alt-X key is being returned a bit differently. They're toggling the 128 bit... I need to look at the alt-Fx keys and see how they're handled. PPS: Aaaaa! All of this would be easier if the driver just converted all the scan/term codes to a standard non-ambigous code -- maybe some sort of unicode. All this legacy stuff outside of the driver is a pita. I know we're stuck with this for the time being but there's gotta be a better way! Keys actions are usually converted somewhere anyway (and both ways) why not pick a reasonable encoding and be consistant. .............................................................................. Newsgroups: comp.terminals References: <35050f5c.0406011602.34071e6c@posting.google.com> <_%kvc.35421$zO3.4532@newsread2.news.atl.earthlink.net> <35050f5c.0406030622.49ef401@posting.google.com> Message-ID: <40BF3A47.80807@nyc.rr.com> Date: Thu, 03 Jun 2004 14:48:35 GMT From: Jeffrey Altman Subject: Re: Best method to recognize Escape vs Escape-Seq in a unix program twisteddweeb@yahoo.com wrote: > > PPS: Aaaaa! All of this would be easier if the driver just converted > all the scan/term codes to a standard non-ambigous code -- maybe some > sort of unicode. All this legacy stuff outside of the driver is a > pita. I know we're stuck with this for the time being but there's > gotta be a better way! Keys actions are usually converted somewhere > anyway (and both ways) why not pick a reasonable encoding and be > consistant. Unfortunately, representing a sequence of single byte values beginning with the value 27d or a sequence of four byte values beginning with 00000027d does not alter the problem. The core of the problem is that people are trying to mix programming models. You either have direct access to the keyboard logic or you don't. Terminals are designed the way they are because the host application does not have direct access to the keyboard logic and instead uses a stream of bytes in which sequences are used to represent single events such as the pressing of a key. For example, to represent the Up keystroke the sequence ESC [ A is sent. Whereas when you have direct access to the keyboard output you can program using scan code sequences representing the up and down events for the various keys. There are terminals which support what is commonly referred to as PCTERM keyboard mode. In this mode, instead of sending ESC sequences and characters to represent what the user typed, the up and down events for each keypress including Shift, Control, Alt, Meta, etc are encoded and sent to the application for interpretation. In this mode the application can clearly distinguish between the pressing of the ESC key from other events because the sequence representing the down and up operations of the key do not involve the use of ESC as a special character sequence. The primary reason that PCTERM keyboard mode is not used is that it is significantly less efficient to send a data structure representing the keyboard state for each change the state; and more importantly it is highly non-portable. Not all keyboards produce the same keycode values for each key on the keyboard. It is up to the local OS driver to perform the mapping from keycodes to their virtual meaning as represented by the keycaps. Of course, PC applications always have direct access to the keyboard logic and never used terminals. Porting these apps as you have discovered leads only to imperfect solutions. My personal complaint regarding apps that rely on timing is that the timing cannot be assured. There is no way for a client terminal communicating over a network or dialup line to guarantee that the sequence ESC [ A will not be broken up either into separate packets or not have other arbitrary delays between bytes be introduced by the communication medium. Therefore, whichever logic is used to identify the standalone ESC is sure to detect false positives. Jeffrey Altman ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.solaris References: <1107688479.502317.284300@o13g2000cwo.googlegroups.com> Message-ID: <110c1o3ntu7e6c9@corp.supernews.com> Date: Sun, 06 Feb 2005 12:01:07 -0000 From: Thomas Dickey Subject: Re: Avoiding ncurses--Solaris 10 x86 + Companion ak%nyangau.fsnet.co.uk wrote: > > I just installed Solaris 10 x86 and masses of stuff from the companion. > I'm using /opt/sfw/bin/gcc to compile a program that uses curses. > /opt/sfw/include/ncurses.h is a symlink to /opt/sfw/include/curses.h. > When I compile my program, regardless of whether I #include > or , I am in fact getting the ncurses header. > This is true, even if I use gcc -I /usr/include. > > If I link with -lcurses, I find the colour doesn't work (despite proper > TERMINFO, TERM and terminfo entry setup), and I get Segmentation > violations--but then again, I wouldn't expect it to work. > If I link with -lncurses, it all works, providing > LD_LIBRARY_PATH=/opt/sfw/lib. I'd simply reinstall ncurses, dispensing with the package (which as you note, is not that useful). The problem is well-known: http://invisible-island.net/ncurses/ncurses.faq.html#compatible_lib and the fix has been available for many years. (Hmm--not ten years yet--sometime in 1995, anyway). > PS, I know the normal terminfo database is somewhat inferior to > /opt/sfw/share/terminfo (e.g., where is xterm-color, what on earth is > xtermc?), but I can always address this by providing "xterm-color.ti". There's a comment in ncurses' terminfo.src about it. Sun's terminfo database does contain several printer entries that are not found in other implementations. "xtermc" exists in a few others. The only references to it being applicable (in the past ten years) are for UnixWare. -- Thomas E. Dickey http://invisible-island.net/ ftp://invisible-island.net/ ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.solaris References: <6cde91hor82jeql681th59jpsks4dr3s1k@4ax.com> Message-ID: <119f21bmfru69bb@corp.supernews.com> Date: Fri, 27 May 2005 20:50:51 -0000 From: Thomas Dickey Subject: Re: vi linux solaris Andreas F. Borchert wrote: > > And you might encounter terminal types that are missing in the ncurses > package but are included in the Solaris set of terminfo entries. You might. Someone mentioned "sun-color" recently, which is not in ncurses. But generally not. And for some that overlap, differences in them generally reflect errors in Sun's database, e.g., "dtterm". -- Thomas E. Dickey ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals References: <1145373613.243516.225800@g10g2000cwb.googlegroups.com> Message-ID: <124a4p56rf91k35@corp.supernews.com> Organization: RadixNet Internet Services Date: Tue, 18 Apr 2006 16:26:13 -0000 From: Thomas Dickey Subject: Re: Getting color in Putty/Secure CRT: Dumb terminal question micotine@gmail.com wrote: > I connect to a Sun sparc system through SecureCRT/Putty. However, I do > not get any colors with directories or xemacs/emacs. Is there anyways, > I can activate them. I have tried following configurations: Hmm--I recently noticed a posting in comp.unix.solaris purportedly from a Sun employee stating that they hadn't updated their terminfo database for ten years (since SunOS 5.4, iirc ;-). [corresponding to Solaris 2.4] > ANSI (with ANSI color) > VT 100 (which I realized does not support color later) yes > my ENV variables from 'env|grep term' were initially > TERM=xterm > ORIG_TERM=xterm > I later set them to TERM='xterm-color' in my .cshrc but then on login I > get the following message > tcsh: using dumb terminal settings. tcsh is not able to find "xterm-color" in the terminal database. That probably does not exist in Sun's terminfo database, unless someone has installed ncurses' terminfo database which would not be in... /usr/share/lib/terminfo but perhaps in... /opt/sfw/share/terminfo "xterm-color" is a misfeature of ncurses that I would like to disown (see my ncurses faq). You can set the TERMINFO variable for this purpose if ncurses' terminfo is installed, but in that case, TERM=putty would be more apt. (I see this host has an old ncurses terminfo: no "putty"). If you don't have a reasonably recent ncurses terminfo database, you're best off setting $TERMINFO to one of your own directories and using tic to install a suitable terminfo. Depending on how old the "Sun sparc" system is, tcsh may be linked with termcap--since it was not originally a Solaris package--and would have been built ad hoc (but a check on this Solaris 8 host shows that the package is installed here, and using terminfo): system SUNWtcsh Tenex C-shell (tcsh) -- Thomas E. Dickey http://invisible-island.net/ ftp://invisible-island.net/ ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.solaris NNTP-Posting-Host: panix2.panix.com NNTP-Posting-Date: Mon, 4 Jul 2005 22:58:51 +0000 (UTC) References: <1120505254.588706.218990@f14g2000cwb.googlegroups.com> Message-ID: Organization: I have a map of the United States that's actual size Date: Mon, 4 Jul 2005 22:58:51 +0000 (UTC) From: Greg Andrews Subject: Re: terminfo "Carlos" writes: > > I mistakenly removed the terminfo directory so I lost vi. > > Can somebody tell me the Solaris 9 package ID that contains a vi > terminfo replacement or be kind in sending me a tar ball from > /usr/share/terminfo, thank you, The package name is SUNWter. -Greg -- Do NOT reply via e-mail. Reply in the newsgroup. .............................................................................. An comprehensive collection of "terminfo" entries, although not supported by Sun, is made available online by Eric Raymond. http://www.catb.org/%7Eesr/terminfo/index.html ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.solaris NNTP-Posting-Date: Wed, 11 Nov 2009 12:30:17 -0600 References: Message-ID: <1257964217.510873@news1nwk> Organization: Sun Microsystems Date: Wed, 11 Nov 2009 13:30:16 -0500 From: Martha Starkey Subject: Re: Why have I got TWO terminfo databases? On 11/11/09 10:51, Charles Lindsey wrote: > > Solaris 10.u1 on a sparc. > > I recently needs gdb (woks better with gcc compiler), so I installed > SFWgdb and also, because it said there was a dependency, SFWncur (both > part of the standard solaris distribution. > > Now lots of applications rely on the terminfo database (e.g. all > terminal=like things such as xterm, dtterm, etc. and also lp), which > includes every known terminal since arounf 1970, and is to be found in > /usr/share/lib/terminfo, which all the relevant applications expect to > find it. It is part of SUNWter, and it comes with associated applications > such as infocmp(1m) and tic(1m). > > BUT SFWncur installs a second terminfo database in > /opt/sfw/share/terminfo, and provides its own versions of infocmp and tic. > > And, in accordance with Murphy's law, the wrong one came first on my PATH, > and also on my MANPATH. > > But how and why did Sun come to have two programs with the same name in > their standard Solaris distribution? I'm not finding anything that indicates that SFWncur was ever included 'bundled' with Solaris. It was on a "Companion CD" (unbundled software, which you add post install) in Solaris 9. It can be downloaded here for both S9 and S10: http://www.sun.com/software/solaris/freeware/ "Now, you have two primary sources of freeware that work with the Solaris 10 Operating System: 1. Freeware that is included on the Solaris 10 CD in separate and distinct modules, which is being made available as a convenience to our customers * technologies that users may expect to find with their operating environment are now included with the Solaris environment 2. Freeware that is co-packaged via the Solaris 10 Companion CD * other useful and popular technologies are offered as an unsupported value-add CD This table contains a summary of the freeware referenced in the above bullets. . . . . . . ." HTH! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Newsgroups: comp.unix.solaris NNTP-Posting-Host: 96.255.132.69 NNTP-Posting-Date: Fri, 13 Nov 2009 10:01:33 +0000 (UTC) References: Message-ID: <700c8a0b-abc5-4e6c-943f-0903eb24fd10@o10g2000yqa.googlegroups.com> Date: Fri, 13 Nov 2009 02:01:33 -0800 (PST) From: Thomas Dickey Subject: Re: Why have I got TWO terminfor databases? On Nov 11, 10:51 am, "Charles Lindsey" wrote: > > Now lots of applications rely on theterminfodatabase (e.g. all > terminal=like things such asxterm, dtterm, etc. and also lp), which > includes every known terminal since arounf 1970, and is to be found in > /usr/share/lib/terminfo, which all the relevant applications expect to > find it. It is part of SUNWter, and it comes with associated applications > such as infocmp(1m) and tic(1m). Sun's terminal database hasn't been maintained for more than ten years (one of Sun's support people proudly commented a few years ago that it hadn't been touched since 1996). So.., if you want to use _anything_ that's been touched since that point, your only recourse is to go to an alternate source. > BUT SFWncur installs a secondterminfodatabase in > /opt/sfw/share/terminfo, and provides its own versions of infocmp and tic. > > And, in accordance with Murphy's law, the wrong one came first on my PATH, > and also on my MANPATH. ncurses' applications, by the way, should be doing what Solaris's do - plus added functionality. (I'm not seeing a bug report here). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Newsgroups: comp.unix.solaris References: <700c8a0b-abc5-4e6c-943f-0903eb24fd10@o10g2000yqa.googlegroups.com> Message-ID: Date: Mon, 16 Nov 2009 15:11:11 GMT From: Charles Lindsey Subject: Re: Why have I got TWO terminfor databases? In <700c8a0b-abc5-4e6c-943f-0903eb24fd10@o10g2000yqa.googlegroups.com> Thomas Dickey writes: > >On Nov 11, 10:51 am, "Charles Lindsey" wrote: >> >> Now lots of applications rely on theterminfodatabase (e.g. all >> terminal=like things such asxterm, dtterm, etc. and also lp), which >> includes every known terminal since arounf 1970, and is to be found in >> /usr/share/lib/terminfo, which all the relevant applications expect to >> find it. It is part of SUNWter, and it comes with associated applications >> such as infocmp(1m) and tic(1m). > Sun's terminal database hasn't been maintained for more than ten years > (one of Sun's support people proudly commented a few years ago that it > hadn't been touched since 1996). > So.., if you want to use _anything_ that's been touched since that point, > your only recourse is to go to an alternate source. But such of Sun's applications that need to consult a terminfo database are hardcoded to look for it in /usr/share/lib. The one that caught me out was 'lp' - I had configued a new Printer Type, and found myself using the wrong version of "tic". Presumably, Gdb is hardcoded to look for it in /opt/share. But there are plenty of native curses applications using Sun's curses lib which will still be looking in /usr/share. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals References: <1108645142.012919.137740@o13g2000cwo.googlegroups.com> <1119cnrs52m7ccc@corp.supernews.com> <1108741221.933727.115680@f14g2000cwb.googlegroups.com> <111cir07ptli332@corp.supernews.com> <26c900dd.0503100215.6b98b982@posting.google.com> <11317gj2so18oe1@corp.supernews.com> Message-ID: <26c900dd.0503180855.1c675a2c@posting.google.com> Date: 18 Mar 2005 08:55:59 -0800 From: Moray Subject: Re: Line draw in PuTTY > Is dialog linked with libncursesw? Also, what does "tic -V" say? The test I described above was on the console (although the same thing does happen in PuTTY). However, #tic -V ncurses 5.4.20040208 #rpm -q dialog ncurses dialog-0.9b-20040606.3om ncurses-5.4-5 #strings /usr/bin/dialog | grep ncurses libncursesw.so.5 (Is there a better way of finding out how dialog is linked?) Kernel is 2.6.9-1.6_FC2, I've got LANG=en_US.UTF-8 on Linux, and Translation UTF-8 in PuTTY. On both console and in PuTTY #TERM=linux dialog --yesno "Hello world\!" 5 30 gives correct line drawing, while #TERM=foo dialog --yesno "Hello world\!" 5 30 gives "Ä" instead of "─", so there must be something wrong either with foo.ti or the way it was compiled. Moray. -- "To err is human. To purr, feline." http://members.aol.com/edgwddirk/ .............................................................................. Newsgroups: comp.terminals References: <1108645142.012919.137740@o13g2000cwo.googlegroups.com> <1119cnrs52m7ccc@corp.supernews.com> <1108741221.933727.115680@f14g2000cwb.googlegroups.com> <111cir07ptli332@corp.supernews.com> <26c900dd.0503100215.6b98b982@posting.google.com> <11317gj2so18oe1@corp.supernews.com> <26c900dd.0503180855.1c675a2c@posting.google.com> Message-ID: <113o3mebrrgtb95@corp.supernews.com> Date: Sat, 19 Mar 2005 11:36:46 -0000 From: Thomas Dickey Subject: Re: Line draw in PuTTY Moray wrote: > > #strings /usr/bin/dialog | grep ncurses > libncursesw.so.5 > (Is there a better way of finding out how dialog is linked?) ldd /usr/bin/dialog though actually I type something like ldd `path dialog` where "path" is a script ftp://invisible-island.net/scripts/path -- Thomas E. Dickey http://invisible-island.net/ ftp://invisible-island.net/ .............................................................................. Newsgroups: comp.terminals References: <1108645142.012919.137740@o13g2000cwo.googlegroups.com> <1119cnrs52m7ccc@corp.supernews.com> <1108741221.933727.115680@f14g2000cwb.googlegroups.com> <111cir07ptli332@corp.supernews.com> <26c900dd.0503100215.6b98b982@posting.google.com> <11317gj2so18oe1@corp.supernews.com> <26c900dd.0503180855.1c675a2c@posting.google.com> <113o3mebrrgtb95@corp.supernews.com> <26c900dd.0503211045.52bbc38@posting.google.com> Message-ID: <113un6ln5tqca3f@corp.supernews.com> Organization: RadixNet Internet Services Date: Mon, 21 Mar 2005 23:46:29 -0000 From: Thomas Dickey Subject: Re: Line draw in PuTTY Moray wrote: >> ldd /usr/bin/dialog > Of course--it's been a long time since I had to do anything at the > library level. Here are some more tests showing the apparent > similarity between the terminfo files, yet the different output they > give. Dialog does not fill in the background colour using TERM=linux > through PuTTY, because bce is set, so I need to edit that out of a > custom copy of the linux terminfo, but as soon as I do so I lose the > unicode linedraw. ... > Wait a minute--what's going on here? The only difference in the > terminfo files is 2 characters in the terminal's name! How does that > make such a huge difference in dialog? Now I'm really confused... I overlooked mentioning it in this thread (but recall a couple of recent discussions): ncurses "knows" that there are a few special cases where the terminal ignores vt100-style line-drawing when in UTF-8 mode. That's "linux" and "screen" (the latter with some additional checks). In the current rollup patch, I've added an environment variable which can be set to tell ncurses to assume this. That's probably what you're seeing (and was too obvious for me to notice). Another thing to note is that there are two sets of line-drawing calls in libncursesw: the narrow calls which are supported in libncurses (and used in dialog), and the wide calls. The narrow calls are the problem, since they normally rely upon the alternate character set capabilities. The wide-character calls can write the Unicode values if the locale is UTF-8. The special case for linux/screen (and whatever else may pop up), tells it to try to use the wide-character equivalents rather than the terminfo data if the locale is UTF-8. It would be nice to just "always" choose the wide-character encoding, but of course there are terminals that don't behave that way--so it has to be configurable in some way. -- Thomas E. Dickey http://invisible-island.net/ ftp://invisible-island.net/ .............................................................................. Newsgroups: comp.terminals NNTP-Posting-Host: 81.5.153.194 NNTP-Posting-Date: Wed, 23 Mar 2005 17:52:38 +0000 (UTC) References: <1108645142.012919.137740@o13g2000cwo.googlegroups.com> <1119cnrs52m7ccc@corp.supernews.com> <1108741221.933727.115680@f14g2000cwb.googlegroups.com> <111cir07ptli332@corp.supernews.com> <26c900dd.0503100215.6b98b982@posting.google.com> <11317gj2so18oe1@corp.supernews.com> <26c900dd.0503180855.1c675a2c@posting.google.com> <113o3mebrrgtb95@corp.supernews.com> <26c900dd.0503211045.52bbc38@posting.google.com> <113un6ln5tqca3f@corp.supernews.com> Message-ID: <26c900dd.0503230952.23aae533@posting.google.com> Date: 23 Mar 2005 09:52:37 -0800 From: Moray Subject: Re: Line draw in PuTTY Thomas Dickey wrote in message news:<113un6ln5tqca3f@corp.supernews.com>... > I overlooked mentioning it in this thread (but recall a couple of recent > discussions): ncurses "knows" that there are a few special cases where the > terminal ignores vt100-style line-drawing when in UTF-8 mode. That's "linux" > and "screen" (the latter with some additional checks). In the current rollup > patch, I've added an environment variable which can be set to tell ncurses to > assume this. Thanks for that. Just for fun, I did try #TERM=screen dialog --yesno "Hello world\!" 5 30 in PuTTY and on the console: in both cases I got "lqqqqqqqqqqqqqqqqqqqqqqqqqqqqk" instead of lines. I guess that is due either to the additional checks you mention, or to the acsc settings in the terminfo files (or possibly both): #infocmp linux screen | grep acsc acsc: '+\020\,\021-\030.^Y0\333`\004a\261f\370g\361h\260i\316j\331k\277l\332m\300n\305o~p\304q\304r\304s_t\303u\264v\301w\302x\263y\363z\362{\343|\330}\234~\376', '++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~'. Anyway, it's not really important. I'll get your patch, and that should give me what I want. Thanks again -- Moray. "To err is human. To purr, feline." http://members.aol.com/edgwddirk .............................................................................. Newsgroups: comp.terminals References: <1108645142.012919.137740@o13g2000cwo.googlegroups.com> <1119cnrs52m7ccc@corp.supernews.com> <1108741221.933727.115680@f14g2000cwb.googlegroups.com> <111cir07ptli332@corp.supernews.com> <26c900dd.0503100215.6b98b982@posting.google.com> <11317gj2so18oe1@corp.supernews.com> <26c900dd.0503180855.1c675a2c@posting.google.com> <113o3mebrrgtb95@corp.supernews.com> <26c900dd.0503211045.52bbc38@posting.google.com> <113un6ln5tqca3f@corp.supernews.com> <26c900dd.0503230952.23aae533@posting.google.com> Message-ID: <1143dt2k0o1jn6f@corp.supernews.com> Organization: RadixNet Internet Services Date: Wed, 23 Mar 2005 18:38:26 -0000 From: Thomas Dickey Subject: Re: Line draw in PuTTY Moray wrote: > > ... > Thanks for that. Just for fun, I did try > > #TERM=screen dialog --yesno "Hello world\!" 5 30 > > in PuTTY and on the console: in both cases I got > "lqqqqqqqqqqqqqqqqqqqqqqqqqqqqk" instead of lines. I guess that is > due either to the additional checks you mention, or to the acsc Yes--it also checks if $TERMCAP is set, and contains lines/columns values. (I don't have the code in front of me, but that's what I recall). > settings in the terminfo files (or possibly both): Yes--it's sending the string for smacs, followed by one or more characters from the acsc string, then rmacs. But PuTTY ignores the smacs/rmacs strings, so all you see is the bytes from the acsc string. > #infocmp linux screen | grep acsc > acsc: '+\020\,\021-\030.^Y0\333`\004a\261f\370g\361h\260i\316j\331k\277l\332m\300n\305o~p\304q\304r\304s_t\303u\264v\301w\302x\263y\363z\362{\343|\330}\234~\376', > '++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~'. > Anyway, it's not really important. I'll get your patch, and that > should give me what I want. > > Thanks again No problem (the new environment variable is documented in the ncurses manpage). -- Thomas E. Dickey http://invisible-island.net/ ftp://invisible-island.net/ ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals NNTP-Posting-Host: 12.8.2.98 NNTP-Posting-Date: Thu, 16 Jun 2005 12:33:41 +0000 (UTC) Message-ID: <1118925215.770888.300480@g14g2000cwa.googlegroups.com> Organization: http://groups.google.com Date: 16 Jun 2005 05:33:35 -0700 From: Chris Subject: Quirky vi Problem We recently migrated to a new hardware platform. The OS is the same (HP-UX 11i). On the old platform, vi worked fine with a custom terminal definition file we have been using. Using that same terminal definition file on the new hardware, I am having some strange problems with vi. The most common problem is when I am attempting to insert characters mid-line. As you type the new characters, the existing characters to the right start to jump around all over the place unpredictably. When you hit escape and ctrl-L the screen redraws perfectly--and everything is where it belongs based on what you have typed. Any ideas? I have already used 'tic' to rebuild the terminal definition binary and it works fine. I'm really at a loss since this terminal definition file worked fine on the old hardware.. Thanks in advance, Chris .............................................................................. Newsgroups: comp.terminals NNTP-Posting-Host: 12.8.2.98 NNTP-Posting-Date: Thu, 16 Jun 2005 20:59:30 +0000 (UTC) References: <1118925215.770888.300480@g14g2000cwa.googlegroups.com> Message-ID: <1118955565.081818.286830@o13g2000cwo.googlegroups.com> Organization: http://groups.google.com Date: 16 Jun 2005 13:59:25 -0700 From: Chris Subject: Re: Quirky vi Problem I don't know that this will help shed any light on the problem--but when I do a "raw" dump of the terminal emulator--I see a lot of "stray" tab characters coming across the line when I am in vi. This is what is messing up my display--and explains perfectly why a ctrl-l redraws the screen the way it is supposed to be. What would cause vi to randomly throw tab chars into the data stream that do not actually exists in the file? If I can get to the root of this question, I think it will solve my problem. Thanks again, Chris .............................................................................. Newsgroups: comp.terminals References: <1118925215.770888.300480@g14g2000cwa.googlegroups.com> <1118955565.081818.286830@o13g2000cwo.googlegroups.com> Message-ID: <11b3ri8h1vafi87@corp.supernews.com> Organization: RadixNet Internet Services Date: Thu, 16 Jun 2005 21:25:28 -0000 From: Thomas Dickey Subject: Re: Quirky vi Problem Chris wrote: > I don't know that this will help shed any light on the problem--but > when I do a "raw" dump of the terminal emulator--I see a lot of > "stray" tab characters coming across the line when I am in vi. This is > what is messing up my display--and explains perfectly why a ctrl-l > redraws the screen the way it is supposed to be. > What would cause vi to randomly throw tab chars into the data stream > that do not actually exists in the file? vi's using curses to optimize repainting of the screen. tab characters are nice (provided that the terminal driver is set to accept them), since they jump up to 8 columns per byte. -- Thomas E. Dickey http://invisible-island.net/ ftp://invisible-island.net/ .............................................................................. Newsgroups: comp.terminals NNTP-Posting-Host: 12.8.2.98 NNTP-Posting-Date: Fri, 17 Jun 2005 18:06:27 +0000 (UTC) References: <1118925215.770888.300480@g14g2000cwa.googlegroups.com> <1118955565.081818.286830@o13g2000cwo.googlegroups.com> <11b3ri8h1vafi87@corp.supernews.com> Message-ID: <1119031581.534307.92610@g47g2000cwa.googlegroups.com> Organization: http://groups.google.com Date: 17 Jun 2005 11:06:21 -0700 From: Chris Subject: Re: Quirky vi Problem Is there somethign I need to do to make curses work with my terminal definition. When I do a untic on the old machine versus the new machine, the two files are identical. I can't figure out what the difference would be here. .............................................................................. Newsgroups: comp.terminals NNTP-Posting-Host: 12.8.2.98 NNTP-Posting-Date: Fri, 17 Jun 2005 18:16:05 +0000 (UTC) References: <1118925215.770888.300480@g14g2000cwa.googlegroups.com> <1118955565.081818.286830@o13g2000cwo.googlegroups.com> <11b3ri8h1vafi87@corp.supernews.com> <1119031581.534307.92610@g47g2000cwa.googlegroups.com> Message-ID: <1119032159.858790.150120@g47g2000cwa.googlegroups.com> Organization: http://groups.google.com Date: 17 Jun 2005 11:15:59 -0700 From: Chris Subject: Re: Quirky vi Problem Ah--with help from another user on a parallel newsgroup we have isolated the cause of the problem. On the old hardware, the -tabs (or tab3) setting was enabled by default. On the new machine it wasn't. By simply issuing a 'stty tab3' at the command line, then looking at the same file--I no longer experienced the problems. Thanks for the assistance here. Chris ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Message-ID: <11adgohabda6v20@corp.supernews.com> References: <11aarsbmun10651@corp.supernews.com> Date: Wed, 08 Jun 2005 10:06:09 -0000 From: Thomas Dickey Subject: Re: Problem with terminfo's sgr Johann 'Myrkraverk' Oskarsson wrote: > Johann 'Myrkraverk' Oskarsson writes: >> I'm pretty sure this is one of them doubly-edged bugs, but do you mind >> telling me what the "sgr" means so I can try to track down the mrxvt >> part of it? I've tried reading the terminfo man page, but I really get >> neither heads nor tails of it ;/ > Nevermind, I got it to the following syntax: > print "\e[0" > if (bold) ";1" ; > if (underline) ";4" ; > if (standout | reverse) ";7" ; > if (blink) ";5" ; > if (invisible) ";8" ; > "m" > if (altcharset) "\e(0" else "\e(B" ; yes--something like that. The termcap-specific problem I mentioned is in the last part (both the sgr and sgr0 string in terminfo set/reset the alternate character set; termcap assumes sgr0 does nothing, so ncurses tries to filter it out--but the filtering was only working for single characters such as ^N). The infocmp "-f" option chops up the string so it's more readable. I usually do something like "infocmp -1f" to read those strings. To see what version of ncurses you have on either machine, the -V option of tic and infocmp gives that information. -- Thomas E. Dickey http://invisible-island.net/ ftp://invisible-island.net/ ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals NNTP-Posting-Host: static-71-246-216-107.washdc.fios.verizon.net NNTP-Posting-Date: Thu, 27 Apr 2006 14:09:34 EDT X-NNTP-Mystery: article repost via above Posting Host References: <1142602383.662642.108420@j52g2000cwj.googlegroups.com> Message-ID: <121m6oeskjvm1f2@corp.supernews.com> Organization: RadixNet Internet Services Date: Thu, 27 Apr 2006 18:09:34 GMT From: Thomas Dickey Subject: Re: Terminal type `screen.linux' is not defined. cyber0ne wrote: > > I'm using screen in my ssh connections to my home server, and I'm > having an issue when I try to run certain terminal applications. Most > recently, when trying to run "procinfo" (which works fine on a local > terminal session), I get the error: > Terminal type `screen.linux' is not defined. For example, if screen is able to find the terminfo entry "screen.linux", and an application uses termcap (which likely isn't as recent as this century). > How can I fix this? add "screen.linux" as an alias for "screen" in /etc/termcap (or the equivalent if you're using something like NetBSD...). -- Thomas E. Dickey ////////////////////////////////////////////////////////////////////////////// As of 2009-11-07, Rasmussen Software is maintaining custom "termcap" and "terminfo" database entries for its Anzio terminal-emulation product: ftp://ftp.anzio.com/pub/anzio_miscellaneous/anzio.tic ftp://ftp.anzio.com/pub/anzio_miscellaneous/anzio.cap ftp://ftp.anzio.com/pub/anzio_miscellaneous/anzio.protermcap //////////////////////////////////////////////////////////////////////////////