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: <telecom13.789.1@eecs.nwu.edu>
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 <roberts@decus.arc.ab.ca>
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 <rsclient@aol.com>
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" <dickey@shell.clark.net>
Newsgroups: comp.terminals
Subject: Re: Creating a vt100 Terminal Application

Peter Smith <rsclient@aol.com> 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: <TRp_2.46$Ku4.2847@iad-read.news.verio.net>
References: <7h2ttb$324$1@nntp9.atl.mindspring.net> <3738af30@news.nwlink.com>
<bK3_2.998$qh4.64826@iad-read.news.verio.net> <3739bdd7@news.nwlink.com>
Date: Thu, 13 May 1999 01:25:07 GMT
From: "T.E.Dickey" <dickey@shell.clark.net>
Newsgroups: comp.terminals
Subject: Re: Creating a vt100 Terminal Application

Peter Smith <rsclient@aol.com> 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: <MBPARKER.93May5110920@netcom3.com>
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.93May5110920@netcom3.com> 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: <p3ekm4-fe3.ln1@paranoia.mcleod-schmidt.id.au>
Date: Sat, 14 Jul 2007 00:17:04 +1000
From: Gary R. Schmidt <grschmidt@acm.org>
Subject: Re: Asking for a sample curses library demo / usage in AIX

richard <yehuu2006(at)gmail.com> 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 <curses.h>

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: <jeffo.758528478@uiuc.edu>
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.758528478@uiuc.edu>,
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: <MGG.94Aug10163625@iceman.triad.com>
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 <std/disclaimer>"

   [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: <BILLB.94Aug10130734@racer-x.bedford.progress.com>
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 <billb@bedford.progress.com> 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: <aeb.782522456@news.cwi.nl>
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>
            <aeb.782522456@news.cwi.nl>
Subject: Re: Line Drawing Characters
Lines: 66

In article <aeb.782522456@news.cwi.nl>, 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 <rohitm%informix.com>
From: "Richard S. Shuford" <shuford%cs.utk.edu>
Subject: Re: Doubt regarding terminal capabilities.
In-Reply-To: <3.0.2.32.19980827132058.00e39ee8@bombay>
Message-ID: <Pine.3.96.980827105823.27662B@cs.utk.edu>

Sir Rohit:

>Date: Thu, 27 Aug 1998 13:20:58 +0500
>From: Rohit <rohitm%informix.com>
>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: <jzeroCz8K81.6Ix@netcom.com> <jzeroCz9GsM.Fpo@netcom.com>
Distribution: inet
Organization: Eindhoven University of Technology, The Netherlands
NNTP-Posting-Host: wsinti05.info.win.tue.nl
Lines: 30


In <jzeroCz9GsM.Fpo@netcom.com> 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= <real code for underline on>   smul=\s<real code for underline on>
ue=<real code for underline off>   rmul=<real code for underline off>\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 "<real code for underline on/off>" 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: <malek.2.2F51EDAD@tor.hookup.net>
Organization: Xylogics Incorporated
From: carlson@Xylogics.COM (James Carlson)
Subject: Re: vt100 Question

In article <malek.2.2F51EDAD@tor.hookup.net>,
 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 <carlson@xylogics.com>            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: <malek.1.2F51EBAE@tor.hookup.net>


In article <malek.1.2F51EBAE@tor.hookup.net>,
 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 <carlson@xylogics.com>            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 <T.Nugent@sct.gu.edu.au> 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
<terminal>" for converting the installed <terminal> 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: <D9yxt2.HMK@stepeng.com>
Followup-To: comp.terminals
References: <ojpRULq00iV5Q3CJ1y@andrew.cmu.edu>
 <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
<dan@stepeng.com>

 //////////////////////////////////////////////////////////////////////////////

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: <DDKpzr.77@stepeng.com>
References: <410m13$qhp@hermes.is.co.za> <411im0$lqo@cs3.brookes.ac.uk>
 <zmbenhalDDJJp3.9Lt@netcom.com>
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 <zmbenhalDDJJp3.9Lt@netcom.com>,
 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 <randolph@pcx.ncd.com>
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 <tschaefe@gate.net> 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 <shuford%cs.utk.edu>
Subject: Re: terminfo files for AIX 2.3

In article <322EB2E4.594F@lincsys.com>,
 Jim Egerton <jegerton@lincsys.com> 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 <esr@snark.thyrsus.com>


 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.sys.hp.hpux
Message-ID: <Eq4HI5.B8r@world.std.com>
References: <351244A1.1BCE@nspuh.cz>
Date: Fri, 20 Mar 1998 14:56:29 GMT
From: Larry M Headlund <lmh@world.std.com>
Subject: Re: curses in 10.20

In article <351244A1.1BCE@nspuh.cz>, Michal Hajek  <hajek@nspuh.cz> 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 <haeb@demon.net>
Subject: Re: Seeking a termcap entry for viewdata (Prestel or Minitel)

On Tue, 29 Sep 1998 12:52:08 +0100, Simon Rawles <radwulf@yahoo.com>
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 <bruce.w.mohler@saic.com>

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 <craig@glasswings.com.au>
Subject: Re: SCO Unix and 3151 Terminal

Peter Gordon <pgordon@cencor.com> 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 <craig@glasswings.com.au>
-----------------------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 <dillon@accelrys.com>
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 <greenemj@hlthsrc.com>
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 <greenemj@hlthsrc.com>
Newsgroups: comp.terminals
Subject: Re: padding, terminfo, and DU4.0d

In article <7p98if$6al$1@nnrp1.deja.com>,
  Mark Greene <greenemj@hlthsrc.com> 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: <acZt3.214$qt5.10505@iad-read.news.verio.net>
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" <dickey@shell.clark.net>
Newsgroups: comp.terminals
Subject: Re: padding, terminfo, and DU4.0d

Mark Greene <greenemj@hlthsrc.com> 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: <slrn8a0iu5.rf3.m.ramsch@melian.forwiss.uni-passau.de>
From: Martin Ramsch <m.ramsch@computer.org>
Subject: Re: Drawing Boxes with ascii chars ?

On Sat, 05 Feb 2000 00:00:04 GMT,
Ake <giake@iol.it> 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 <m.ramsch@computer.org> <URL: http://home.pages.de/~ramsch/ >
PGP KeyID=0xE8EF4F75 FiPr=5244 5EF3 B0B1 3826  E4EC 8058 7B31 3AD7


 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.unix.questions
References: <m3sninia1x.fsf@gnus.cvs.983032537>
            <GCr9sH.1r3@fcshome.stoneham.ma.us>
Date: 4 May 2001 10:33:38 GMT
Organization: RadixNet Internet Services
Message-ID: <9cu0i2$4h$3@news1.Radix.Net>
From: Thomas Dickey <dickey@saltmine.radix.net>
Subject: Re: $TERM wars

fred smith <fredex@fcshome.stoneham.ma.us> 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 <terminfo filename>
> 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 <dickey@radix.net> <dickey@herndon4.his.com>
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 <dickey@saltmine.radix.net>
Subject: Re: wyse85 function keys
Jim <microsyseng@rcn.com> 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 <dickey@radix.net> <dickey@herndon4.his.com>
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 <dickey@saltmine.radix.net>
Subject: Re: Terminal problem with ncurses

Julian Regel <jregel@acadinfo.co.uk> 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 <dickey@radix.net> <dickey@herndon4.his.com>
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 <dickey@saltmine.radix.net>
Subject: Re: [ncurses]: why not the right colors ?

Thomas Baruchel <baruchel@libertysurf.france> 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 <dickey@radix.net> <dickey@herndon4.his.com>


 //////////////////////////////////////////////////////////////////////////////


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 <baruchel@libertysurf.france>
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 <dickey@saltmine.radix.net>
Subject: Re: Is it possible to use readline with ncurses ?

Thomas Baruchel <baruchel@libertysurf.france> 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 <dickey@radix.net>


 //////////////////////////////////////////////////////////////////////////////

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 <dickey@saltmine.radix.net>
Subject: Re: [ncurses+panel] update_panels() + doupdate ()

Thomas Baruchel <baruchel@libertysurf.france> 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 <dickey@radix.net> <dickey@herndon4.his.com>
http://dickey.his.com
 ftp://dickey.his.com


 //////////////////////////////////////////////////////////////////////////////


Newsgroups: comp.sys.hp.hpux, comp.unix.admin
Message-ID: <m38zckwenz.fsf@gryphon.myth.atl.mediaone.net>
Date: Mon, 03 Dec 2001 14:32:05 GMT
From: Chuck Mattern <cmattern@mediaone.net>
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: <m38zckwenz.fsf@gryphon.myth.atl.mediaone.net>
Message-ID: <3C0BA8B2.458A1915@accelrys.com>
Organization: Accelrys Inc.
Date: Mon, 03 Dec 2001 10:30:42 -0600
From: Chuck Dillon <dillon@accelrys.com>
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: <m38zckwenz.fsf@gryphon.myth.atl.mediaone.net>
    <3C0BA8B2.458A1915@accelrys.com>
Message-ID: <m3u1v8au2s.fsf@gryphon.myth.atl.mediaone.net>
Date: Mon, 03 Dec 2001 21:02:19 GMT
From: Chuck Mattern <cmattern@mediaone.net>
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: <m38zckwenz.fsf@gryphon.myth.atl.mediaone.net>
    <3C0BE036.CBC4BEF3@boeing.com>
Message-ID: <m3itbn6zq4.fsf@gryphon.myth.atl.mediaone.net>
Date: Tue, 04 Dec 2001 10:26:09 GMT
From: Chuck Mattern <cmattern@mediaone.net>
Subject: Re: termcap null ops?

Robert Gilster <robert.l.gilster@boeing.com> 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 <norbert.kaufmann@schlund.de>
Subject: Re: ncurses

In article <20020124104410.4dc54ea9.tberkopes@indy.rr.com>, "TonyB"
<tberkopes@indy.rr.com> 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> <ae3ai7$nu0$1@nenevr.demon.co.uk>
    <32D2E960.18AB7B2E@yahoo.com> <aeg1s1$j60$1@nenevr.demon.co.uk>
    <aej0bo$5tk$3@news1.Radix.Net> <aelnbj$9gr$1@nenevr.demon.co.uk>
    <Xns9231D39EF4470newscelignecouk@216.168.3.30>
Message-ID: <aeoi3i$hg6$2@news1.Radix.Net>
Organization: RadixNet Internet Services
Date: 19 Jun 2002 00:09:22 GMT
From: Thomas Dickey <dickey@saltmine.radix.net>
Subject: Re: Dec VT220 backspace help

Paul Williams <news@celigne.co.uk> wrote:
> Simon Coombs <simon@nenevr.demon.co.uk> 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 <dickey@radix.net> <dickey@herndon4.his.com>
http://dickey.his.com
ftp://dickey.his.com


 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.terminals
References: <32CCC4FB.DFA6041B@yahoo.com> <ae3ai7$nu0$1@nenevr.demon.co.uk>
    <32D2E960.18AB7B2E@yahoo.com> <aeg1s1$j60$1@nenevr.demon.co.uk>
    <aej0bo$5tk$3@news1.Radix.Net> <aelnbj$9gr$1@nenevr.demon.co.uk>
Message-ID: <aeohnb$hg6$1@news1.Radix.Net>
Organization: RadixNet Internet Services
Date: 19 Jun 2002 00:02:51 GMT
From: Thomas Dickey <dickey@saltmine.radix.net>
Subject: Re: Dec VT220 backspace help

Simon Coombs <simon@nenevr.demon.co.uk> wrote:
> Thomas Dickey <dickey@saltmine.radix.net> 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 $<number> 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 <dickey@radix.net> <dickey@herndon4.his.com>
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 <Casper.Dik@Sun.COM>
Subject: Re: terminfo source for "ansi" Solaris 10

Wayne Rasmussen <Xvirtual2DoNotSpamMe@gomonarch.com> 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: <af2mjt$b85ru$2@ID-21915.news.dfncis.de>
Organization: Hofheim/Taunus, Germany
Date: 22 Jun 2002 20:27:42 GMT
From: Joerg Klemenz <joerg@gmx.net>
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: <af2mjt$b85ru$2@ID-21915.news.dfncis.de>
    <8ef44c8eafa869a6@mayday.cix.co.uk>
Message-ID: <af7ren$ca5qp$3@ID-21915.news.dfncis.de>
Organization: Hofheim/Taunus, Germany
Date: 24 Jun 2002 19:20:55 GMT
From: Joerg Klemenz <joerg@gmx.net>
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: <afdh2e$d82e8$1@ID-21915.news.dfncis.de>
    <afkhuu$903$1@news1.Radix.Net> <afl1o7$f2seo$1@ID-21915.news.dfncis.de>
    <afmois$jib$1@news1.Radix.Net> <afqqee$galoh$1@ID-21915.news.dfncis.de>
Message-ID: <afrvkm$1va$1@news1.Radix.Net>
Organization: RadixNet Internet Services
Date: 2 Jul 2002 10:35:02 GMT
From: Thomas Dickey <dickey@saltmine.radix.net>
Subject: Re: Urlview broken?

Joerg Klemenz <joerg@gmx.net> wrote:
> Thomas Dickey wrote:
>> Joerg Klemenz <joerg@gmx.net> 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 <i><^V><up-arrow> 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 <dickey@radix.net> <dickey@herndon4.his.com>
http://dickey.his.com/
 ftp://dickey.his.com/

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.terminals
References: <afdh2e$d82e8$1@ID-21915.news.dfncis.de>
    <afkhuu$903$1@news1.Radix.Net> <afl1o7$f2seo$1@ID-21915.news.dfncis.de>
    <afmois$jib$1@news1.Radix.Net> <afqqee$galoh$1@ID-21915.news.dfncis.de>
    <afrvkm$1va$1@news1.Radix.Net>
Message-ID: <afte0h$hbsb5$2@ID-21915.news.dfncis.de>
Organization: Hofheim/Taunus, Germany
Date: 2 Jul 2002 23:46:28 GMT
From: Joerg Klemenz <joerg@gmx.net>
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: <afdh2e$d82e8$1@ID-21915.news.dfncis.de>
    <afkhuu$903$1@news1.Radix.Net> <afl1o7$f2seo$1@ID-21915.news.dfncis.de>
    <afmois$jib$1@news1.Radix.Net> <afqqee$galoh$1@ID-21915.news.dfncis.de>
    <afrvkm$1va$1@news1.Radix.Net> <afte0h$hbsb5$2@ID-21915.news.dfncis.de>
Message-ID: <afugn8$jeg$1@news1.Radix.Net>
Organization: RadixNet Internet Services
Date: 3 Jul 2002 09:38:48 GMT
From: Thomas Dickey <dickey@saltmine.radix.net>
Subject: Re: Urlview broken?

Joerg Klemenz <joerg@gmx.net> 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 <dickey@radix.net> <dickey@herndon4.his.com>
http://dickey.his.com
 ftp://dickey.his.com

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.terminals
References: <afdh2e$d82e8$1@ID-21915.news.dfncis.de>
    <afkhuu$903$1@news1.Radix.Net> <afl1o7$f2seo$1@ID-21915.news.dfncis.de>
    <afmois$jib$1@news1.Radix.Net> <afqqee$galoh$1@ID-21915.news.dfncis.de>
    <afrvkm$1va$1@news1.Radix.Net> <afte0h$hbsb5$2@ID-21915.news.dfncis.de>
    <afugn8$jeg$1@news1.Radix.Net>
Message-ID: <ag2nm6$igp7t$1@ID-21915.news.dfncis.de>
Organization: Hofheim/Taunus, Germany
Date: 5 Jul 2002 00:02:16 GMT
From: Joerg Klemenz <joerg@gmx.net>
Subject: Re: Urlview broken?

Thomas Dickey wrote:
> 
> Joerg Klemenz <joerg@gmx.net> 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 <i><^V><up-arrow> 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: <afdh2e$d82e8$1@ID-21915.news.dfncis.de>
    <afkhuu$903$1@news1.Radix.Net> <afl1o7$f2seo$1@ID-21915.news.dfncis.de>
    <afmois$jib$1@news1.Radix.Net> <afqqee$galoh$1@ID-21915.news.dfncis.de>
    <afrvkm$1va$1@news1.Radix.Net> <afte0h$hbsb5$2@ID-21915.news.dfncis.de>
    <afugn8$jeg$1@news1.Radix.Net> <ag2nm6$igp7t$1@ID-21915.news.dfncis.de>
Message-ID: <ag3qkn$oh$1@news1.Radix.Net>
Date: 5 Jul 2002 09:58:47 GMT
From: Thomas Dickey <dickey@saltmine.radix.net>
Subject: Re: Urlview broken?

Joerg Klemenz <joerg@gmx.net> 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 <dickey@radix.net> <dickey@herndon4.his.com>
http://dickey.his.com
 ftp://dickey.his.com

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.unix.bsd.freebsd.misc
References: <aiqcbi$162e6j$1@ID-117651.news.dfncis.de>
    <slrnal1nt2.1ucs.&-@jazz.hq.newdream.net>
    <aiqqt5$15uueu$1@ID-117651.news.dfncis.de>
    <slrnal2scj.1ucs.&-@jazz.hq.newdream.net>
    <3D525097.10874143@SPAMFILTERdavepimlott.info>
    <slrnal4n1u.1vtk.&-@jazz.hq.newdream.net>
    <20020808204443.38ab4816.steveo@eircom.net> <aiuosv$2ta$1@news1.Radix.Net>
    <slrnal6cfi.20rn.&-@jazz.hq.newdream.net>
Message-ID: <aj0m9k$a12$1@news1.Radix.Net>
Date: 9 Aug 2002 15:15:00 GMT
From: Thomas Dickey <dickey@saltmine.radix.net>
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 <dickey@radix.net> <dickey@herndon4.his.com>
http://dickey.his.com/
 ftp://dickey.his.com/

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.unix.bsd.freebsd.misc
References: <aiqcbi$162e6j$1@ID-117651.news.dfncis.de>
    <slrnal1nt2.1ucs.&-@jazz.hq.newdream.net>
    <aiqqt5$15uueu$1@ID-117651.news.dfncis.de>
    <slrnal2scj.1ucs.&-@jazz.hq.newdream.net>
    <3D525097.10874143@SPAMFILTERdavepimlott.info>
    <slrnal4n1u.1vtk.&-@jazz.hq.newdream.net>
    <20020808204443.38ab4816.steveo@eircom.net> <aiuosv$2ta$1@news1.Radix.Net>
    <slrnal6cfi.20rn.&-@jazz.hq.newdream.net> <aj0m9k$a12$1@news1.Radix.Net>
Message-ID: <slrnal8st0.227g.&-@jazz.hq.newdream.net>
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 <aj0m9k$a12$1@news1.Radix.Net>, 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: <aiqcbi$162e6j$1@ID-117651.news.dfncis.de>
    <slrnal1nt2.1ucs.&-@jazz.hq.newdream.net>
    <aiqqt5$15uueu$1@ID-117651.news.dfncis.de>
    <slrnal2scj.1ucs.&-@jazz.hq.newdream.net>
    <3D525097.10874143@SPAMFILTERdavepimlott.info>
    <slrnal4n1u.1vtk.&-@jazz.hq.newdream.net>
    <20020808204443.38ab4816.steveo@eircom.net> <aiuosv$2ta$1@news1.Radix.Net>
    <slrnal6cfi.20rn.&-@jazz.hq.newdream.net> <aj0m9k$a12$1@news1.Radix.Net>
    <slrnal8st0.227g.&-@jazz.hq.newdream.net>
Message-ID: <aj3m6o$85t$1@news1.Radix.Net>
Organization: RadixNet Internet Services
Date: 10 Aug 2002 18:31:52 GMT
From: Thomas Dickey <dickey@saltmine.radix.net>
Subject: Re: Eterm termcap entry (was Re: TERM)

Will Yardley <&-@no.spam.veggiechinese.net> wrote:
> In article <aj0m9k$a12$1@news1.Radix.Net>, 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 <dickey@radix.net> <dickey@herndon4.his.com>
http://dickey.his.com/
 ftp://dickey.his.com/


 //////////////////////////////////////////////////////////////////////////////

Date: 31 Oct 2002 11:27:48 GMT
Newsgroups: comp.unix.solaris
Message-ID: <apr43k$lkt$1@news1.radix.net>
References: <49d864eb.0210301757.19eb4d20@posting.google.com>
From: Thomas Dickey <dickey@saltmine.radix.net>
Subject: Re: ncurses on Solaris

Quang <quang_net@hotmail.com> 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 <dickey@radix.net> <dickey@herndon4.his.com>

 //////////////////////////////////////////////////////////////////////////////

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>
    <apr43k$lkt$1@news1.radix.net>
From: Quang <quang_net@hotmail.com>
Subject: Re: ncurses on Solaris

Thomas Dickey <dickey@saltmine.radix.net> wrote in message
news:<apr43k$lkt$1@news1.radix.net>...

> 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: <apslb7$k61$1@news1.radix.net>
References: <49d864eb.0210301757.19eb4d20@posting.google.com>
    <apr43k$lkt$1@news1.radix.net> <49d864eb.0210311434.6f321e79@posting.google.com>
From: Thomas Dickey <dickey@saltmine.radix.net>
Subject: Re: ncurses on Solaris

Quang <quang_net@hotmail.com> 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 <dickey@radix.net> <dickey@herndon4.his.com>


 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.terminals
References: <3e5f2986$0$234$626a54ce@news.free.fr>
Message-ID: <b3nlra$q30$1@news1.radix.net>
Date: 28 Feb 2003 12:48:42 GMT
From: Thomas Dickey <dickey@saltmine.radix.net>
Subject: Re: ncurses and Win

"Herv" <hpeignelin_nospam@freesurf.fr> 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 <dickey@radix.net> <dickey@herndon4.his.com>

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.terminals
References: <b3lj3l$44u$07$1@news.t-online.com>
Message-ID: <b3nluk$q30$2@news1.radix.net>
Date: 28 Feb 2003 12:50:28 GMT
From: Thomas Dickey <dickey@saltmine.radix.net>
Subject: Re: ncurses and terminal

Matthias Pieroth <matthias.pieroth@t-online.de> 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 <dickey@radix.net> <dickey@herndon4.his.com>

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.terminals
References: <b3lj3l$44u$07$1@news.t-online.com>
    <b3nluk$q30$2@news1.radix.net> <b3noc4$qed$01$1@news.t-online.com>
Message-ID: <b3nu07$1ga$1@news1.radix.net>
Date: 28 Feb 2003 15:07:51 GMT
From: Thomas Dickey <dickey@saltmine.radix.net>
Subject: Re: ncurses and terminal

Matthias Pieroth <matthias.pieroth@t-online.de> 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 <dickey@radix.net> <dickey@herndon4.his.com>

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.unix.programmer
Message-ID: <pan.2003.04.08.18.26.57.802562.927@t-online.de>
Date: Tue, 08 Apr 2003 18:26:57 +0200
From: Michael Steinbauer <j.m.steinbauer@t-online.de>
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: <b6vppa$boa$2@news1.radix.net>
References: <pan.2003.04.08.23.41.58.386751.917@t-online.de>
	<pan.2003.04.08.18.26.57.802562.927@t-online.de>
Date: Wed, 9 Apr 2003 00:33:46 GMT
From: Thomas Dickey <dickey@saltmine.radix.net>
Subject: Re: ncurses 'field' to string transfer.

Michael Steinbauer <j.m.steinbauer@t-online.de> 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 <dickey@radix.net> <dickey@herndon4.his.com>
http://dickey.his.com/
 ftp://dickey.his.com/


 //////////////////////////////////////////////////////////////////////////////

Newsgroups: alt.folklore.computers
Message-ID: <1716.235T2368T12505901@kltpzyxm.invalid>
References: <b73pco$2j0m$1@citadel.in.taronga.com>
    <1825.230T1674T5474619@kltpzyxm.invalid> <3E95BE41.8F39F3B8@yahoo.com>
    <slrnb9j1pt.g3k.als@thangorodrim.de> <3E99D6FD.92831B5F@yahoo.com>
    <a59f7b.mei.ln@escape.shannon.net>
Organization: http://extra.newsguy.com
Date: 15 Apr 03 20:50:47 -0800
From: Charlie Gibbs <cgibbs@kltpzyxm.invalid>
Subject: Re: Any DEC 340 Display System Doco ?

In article <a59f7b.mei.ln@escape.shannon.net> 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: <b7jhi8$1opn$1@citadel.in.taronga.com>
References: <3e8ae086.45754328@news.m.iinet.net.au>
    <slrnb9j1pt.g3k.als@thangorodrim.de> <3E99D6FD.92831B5F@yahoo.com>
    <a59f7b.mei.ln@escape.shannon.net>
Organization: TSS Inc.
Date: 16 Apr 2003 12:16:08 GMT
From: Peter da Silva <peter@taronga.com>
Subject: Re: Any DEC 340 Display System Doco ?

In article <a59f7b.mei.ln@escape.shannon.net>,
Charles Shannon Hendrix  <cshSPAM@SPAM.widomaker.com> 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: <pan.2003.08.19.12.46.58.546298@sneakemail.com>
    <bhu6hg$ev6$1@news1.radix.net>
    <pan.2003.08.19.23.00.45.100113@sneakemail.com>
    <bhvn30$pfs$1@news1.radix.net>
    <pan.2003.08.20.13.44.28.250857@sneakemail.com>
    <bi0ab4$jhi$1@news1.radix.net>
    <pan.2003.08.20.18.41.16.887972@sneakemail.com>
Message-ID: <bibdkb$nfv$2@news1.radix.net>
Date: 24 Aug 2003 22:18:51 GMT
From: Thomas Dickey <dickey@saltmine.radix.net>
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 <dickey@radix.net> <dickey@herndon4.his.com>
http://dickey.his.com/
 ftp://dickey.his.com/


 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.unix.solaris
NNTP-Posting-Host: saltmine.radix.net
References: <ddf392ea.0311050944.d0eb9a0@posting.google.com>
    <boj7r3$hc1$2@news1.radix.net> <boj983$7mn$1@news.cs.tu-berlin.de>
    <bojqtg$78s$1@news1.radix.net> <bojtee$grp$1@news.cs.tu-berlin.de>
Message-ID: <bok6hm$ib6$3@news1.radix.net>
Date: 9 Nov 2003 01:50:46 GMT
From: Thomas Dickey <dickey@saltmine.radix.net>
Subject: Re: Setting 132 columns in Solaris

Joerg Schilling <js@cs.tu-berlin.de> 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 <thomas.baruchel@libertysurf.fr>
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, Mtaphysique des moeurs, doctrine du droit, II conclusion)

  Thomas Baruchel <thomas.baruchel@laposte.net>

 ..............................................................................

Newsgroups: comp.terminals
Message-ID: <slrnbrpi3e.45.stephane.chazelas@spam.is.invalid>
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 <this.address@is.invalid>
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[3<x>m' sequences without even
bother with terminfo, that's what some applications do (see
elinks, info -f zsh --index-search=colors)

-- 
Stphane                      ["Stephane.Chazelas" at "free.fr"]

 ..............................................................................

Newsgroups: comp.terminals
Message-ID: <slrnbrpifo.45.stephane.chazelas@spam.is.invalid>
References: <3fbc8b9c$0$27051$626a54ce@news.free.fr>
    <slrnbrpi3e.45.stephane.chazelas@spam.is.invalid>
Organization: Guest of ProXad--France
Date: Thu, 20 Nov 2003 15:04:40 +0100
From: Stephane CHAZELAS <this.address@is.invalid>
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).


-- 
Stphane                      ["Stephane.Chazelas" at "free.fr"]

 ..............................................................................

Newsgroups: comp.terminals
Message-ID: <bpikqb$302$1@news1.radix.net>
References: <3fbc8b9c$0$27051$626a54ce@news.free.fr>
    <slrnbrpi3e.45.stephane.chazelas@spam.is.invalid>
Date: 20 Nov 2003 14:58:19 GMT
From: Thomas Dickey <dickey@saltmine.radix.net>
Subject: Re: Using terminfo (curses)

Stephane CHAZELAS <this.address@is.invalid> 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: <slrnbrpqq9.1bq.stephane.chazelas@spam.is.invalid>
References: <3fbc8b9c$0$27051$626a54ce@news.free.fr>
    <slrnbrpi3e.45.stephane.chazelas@spam.is.invalid>
    <bpikqb$302$1@news1.radix.net>
Organization: Guest of ProXad--France
Date: Thu, 20 Nov 2003 17:26:49 +0100
From: Stephane CHAZELAS <this.address@is.invalid>
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)?

-- 
Stphane                      ["Stephane.Chazelas" at "free.fr"]

 ..............................................................................

Newsgroups: comp.terminals
Message-ID: <bpkuov$ab$1@news1.radix.net>
References: <3fbc8b9c$0$27051$626a54ce@news.free.fr>
    <slrnbrpi3e.45.stephane.chazelas@spam.is.invalid>
    <bpikqb$302$1@news1.radix.net>
    <slrnbrpqq9.1bq.stephane.chazelas@spam.is.invalid>
Date: 21 Nov 2003 12:00:31 GMT
From: Thomas Dickey <dickey@saltmine.radix.net>
Subject: Re: Using terminfo (curses)

Stephane CHAZELAS <this.address@is.invalid> 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: <p20186-kul.ln1@neptune.markhobley.yi.org>
    <slrngqtgsl.fc1.stephane.chazelas@spam.is.invalid>
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 <dickey@invisible-island.net>
Subject: Re: tput: why does setb and setf not work, but setab and setaf do?

In comp.terminals Stephane CHAZELAS <stephane_chazelas@yahoo.fr> 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: <slrndb8i15.9nj.nospam@gatsby.mbjnet.dk>
Date: Sat, 18 Jun 2005 19:44:32 -0000
From: Thomas Dickey <dickey@saltmine.radix.net>
Subject: Re: Bold attribute not working with xterm-256color

Morten Bo Johansen <nospam@mbjnet.dk> 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 <Casper.Dik@Sun.COM>
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: <hdSrc.19138$zO3.4497@newsread2.news.atl.earthlink.net>
Organization: EarthLink Inc. -- http://www.EarthLink.net
Date: Sun, 23 May 2004 00:26:53 GMT
From: Kevin L <kevinl01@earthlink.net>
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: <hdSrc.19138$zO3.4497@newsread2.news.atl.earthlink.net>
Message-ID: <barmar-93AB41.21023622052004@comcast.dca.giganews.com>
Organization: Looking for work
Date: Sat, 22 May 2004 21:02:36 -0400
From: Barry Margolin <barmar@alum.mit.edu>
Subject: Re: Terminfo:  how to interrogate without changing MY term?

In article <hdSrc.19138$zO3.4497@newsread2.news.atl.earthlink.net>,
 Kevin L <kevinl01@earthlink.net> 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: <hdSrc.19138$zO3.4497@newsread2.news.atl.earthlink.net>
Message-ID: <10avver44c2t52d@corp.supernews.com>
Date: Sun, 23 May 2004 01:26:51 -0000
From: Thomas Dickey <dickey@saltmine.radix.net>
Subject: Re: Terminfo:  how to interrogate without changing MY term?

In comp.terminals Kevin L <kevinl01@earthlink.net> 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: <hdSrc.19138$zO3.4497@newsread2.news.atl.earthlink.net>
    <10avver44c2t52d@corp.supernews.com>
Message-ID: <IyUrc.28036$KE6.11961@newsread3.news.atl.earthlink.net>
Organization: EarthLink Inc. -- http://www.EarthLink.net
Date: Sun, 23 May 2004 03:06:16 GMT
From: Kevin L <kevinl01@earthlink.net>
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: <hdSrc.19138$zO3.4497@newsread2.news.atl.earthlink.net>
    <10avver44c2t52d@corp.supernews.com>
    <IyUrc.28036$KE6.11961@newsread3.news.atl.earthlink.net>
Message-ID: <10b62jpgu43ns53@corp.supernews.com>
Date: Tue, 25 May 2004 08:57:29 -0000
From: Thomas Dickey <dickey@saltmine.radix.net>
Subject: Re: Terminfo:  how to interrogate without changing MY term?

In comp.terminals Thomas Dickey <dickey@saltmine.radix.net> 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 <kevinl01@earthlink.net> 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: <jaltman2@nyc.rr.com>
From: Jeffrey Altman <jaltman at mit dot edu>
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: <rshu_20040601235750@stratagy.com>
Organization: The Late, Great Stratagy Users Group
Date: Tue, 1 Jun 2004 23:57:50 -0400
From: Richard S. Shuford <shuford@list.stratagy.REM0VE-THlS-PART.com>
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 <kevinl01@earthlink.net>
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
<ESC>[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-<keystroke> or META-<keystroke> 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-<keystroke> 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 <jaltman2@nyc.rr.com>
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 <dickey@saltmine.radix.net>
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 <curses.h>
> or <ncurses.h>, 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>
    <slrnd9eu5m.cm8.comp.unix.solaris@usenet.andreas-borchert.de>
Message-ID: <119f21bmfru69bb@corp.supernews.com>
Date: Fri, 27 May 2005 20:50:51 -0000
From: Thomas Dickey <dickey@saltmine.radix.net>
Subject: Re: vi linux solaris

Andreas F. Borchert
<comp.unix.solaris@expires-on-2005-06-04.usenet.andreas-borchert.de> 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 <dickey@saltmine.radix.net>
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: <dacevb$r6$1@reader2.panix.com>
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 <gerg@panix.com>
Subject: Re: terminfo

"Carlos" <carlos@istamina.com.ar> 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: <KsyC1J.2Dx@clerew.man.ac.uk>
Message-ID: <1257964217.510873@news1nwk>
Organization: Sun Microsystems
Date: Wed, 11 Nov 2009 13:30:16 -0500
From: Martha Starkey <martha.starkey@sun.com>
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: <KsyC1J.2Dx@clerew.man.ac.uk>
Message-ID: <700c8a0b-abc5-4e6c-943f-0903eb24fd10@o10g2000yqa.googlegroups.com>
Date: Fri, 13 Nov 2009 02:01:33 -0800 (PST)
From: Thomas Dickey <dickey@his.com>
Subject: Re: Why have I got TWO terminfor databases?

On Nov 11, 10:51am, "Charles Lindsey" <c...@clerew.man.ac.uk> 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 <dickey@invisible-island.net>
http://invisible-island.net
 ftp://invisible-island.net

 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Newsgroups: comp.unix.solaris
References: <KsyC1J.2Dx@clerew.man.ac.uk>
      <700c8a0b-abc5-4e6c-943f-0903eb24fd10@o10g2000yqa.googlegroups.com>
Message-ID: <Kt7JIn.9D4@clerew.man.ac.uk>
Date: Mon, 16 Nov 2009 15:11:11 GMT
From: Charles Lindsey <chl@clerew.man.ac.uk>
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" <c...@clerew.man.ac.uk> 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 <X0D0F120119@aol.com>
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 "&#9472;", 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 <dickey@saltmine.radix.net>
Subject: Re: Line draw in PuTTY

Moray <X0D0F120119@aol.com> 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 <dickey@saltmine.radix.net>
Subject: Re: Line draw in PuTTY

Moray <X0D0F120119@aol.com> 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 <X0D0F120119@aol.com>
Subject: Re: Line draw in PuTTY

Thomas Dickey <dickey@saltmine.radix.net> 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 <dickey@saltmine.radix.net>
Subject: Re: Line draw in PuTTY

Moray <X0D0F120119@aol.com> 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 <ctaliercio@yahoo.com>
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 <ctaliercio@yahoo.com>
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 <dickey@saltmine.radix.net>
Subject: Re: Quirky vi Problem

Chris <ctaliercio@yahoo.com> 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 <ctaliercio@yahoo.com>
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 <ctaliercio@yahoo.com>
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: <m3acm4dz0r.fsf@jin.myrkraverk.com>
            <11aarsbmun10651@corp.supernews.com>
            <m34qc9d5w6.fsf@jin.myrkraverk.com>
            <m3vf4pbfye.fsf@jin.myrkraverk.com>
Date: Wed, 08 Jun 2005 10:06:09 -0000
From: Thomas Dickey <dickey@saltmine.radix.net>
Subject: Re: Problem with terminfo's sgr

Johann 'Myrkraverk' Oskarsson <myrkraverk@users.sourceforget.net> wrote:
> Johann 'Myrkraverk' Oskarsson <myrkraverk@users.sourceforget.net> 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 <dickey@saltmine.radix.net>
Subject: Re: Terminal type `screen.linux' is not defined.

cyber0ne <cyber0ne1*gmail.com> 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

 //////////////////////////////////////////////////////////////////////////////
