1# 2# CDDL HEADER START 3# 4# The contents of this file are subject to the terms of the 5# Common Development and Distribution License, Version 1.0 only 6# (the "License"). You may not use this file except in compliance 7# with the License. 8# 9# You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE 10# or http://www.opensolaris.org/os/licensing. 11# See the License for the specific language governing permissions 12# and limitations under the License. 13# 14# When distributing Covered Code, include this CDDL HEADER in each 15# file and include the License file at usr/src/OPENSOLARIS.LICENSE. 16# If applicable, add the following below this CDDL HEADER, with the 17# fields enclosed by brackets "[]" replaced with your own identifying 18# information: Portions Copyright [yyyy] [name of copyright owner] 19# 20# CDDL HEADER END 21# 22#ident "%Z%%M% %I% %E% SMI" SVr4.0 1.6 23# From: SVr4.0 terminfo:README 1.6 24 25 261 Within the curses component, exists other conversion tools which are 27 much more robust than those described below. They are called infocmp, 28 and captoinfo. The cvt files are provided here only for those possible 29 cases where a user has the terminfo component without the libcurses 30 component. 31 32 The captoinfo and infocmp utilities cannot be included here, as they 33 require the user to have libcurses. Although we know of no instance 34 when a user would have one and not the other, we have provided the 35 cvt files (described below) for those limited cases. 36 37 38 392 The files in this directory with the .ti suffix are terminfo sources. 40 They should be compiled (separately or by catting them together into 41 terminfo.src) with tic, placing the results in /usr/lib/terminfo. 42 Please send any updates to AT&T Bell Laboratories UNIX support, 43 via UNIX mail to attunix!terminfo. 44 45 46 473 The cvt files are useful tools for converting termcap to terminfo. 48 They are not 100% accurate, but do most of the conversion for you. 49 cvt.ex is an ex script to convert a termcap description into a 50 terminfo description. Note that it will not convert padding 51 specifications, so they must be done by hand. Note also that typical 52 termcap entries do not give as much information as terminfo, so the 53 resulting terminfo entry is often incomplete (e.g. won't tell you the 54 terminal uses xon/xoff handshaking, or what extra function keys send). 55 You are urged to read the list of terminfo capabilities and augment your 56 terminfo descriptions accordingly. 57 58 The cvt.h file is useful for a quick hack at converting termcap programs 59 which use uppercase 2 letter names for capabilities to use terminfo. 60 Since tget* are provided anyway, this is of questionable value unless 61 your program barely fits on a pdp-11. 62 63 The cvt.sed script is useful for actually editing the source of the same 64 class of programs. It requires a sed that understands \< and \>, the 65 mod is trivial to make if you look at the corresponding code in ex or 66 grep. 67 68 69 703 There are other incompatibilities at the user level between termcap and 71 terminfo. A program which creates a termcap description and then 72 passes it to tgetent (e.g. vi used to do this if no TERM was set) or 73 which puts such a description in the environment for a child cannot 74 possibly work, since terminfo puts the parser into the compiler, not 75 the user program. If you want to give a child a smaller window, set 76 up the LINES and COLUMNS environment variables or implement the JWINSIZE 77 ioctl. 78 79 80 814 If you want to edit your own personal terminfo descriptions (and are not 82 a super user on your system) the method is different. Set 83 TERMINFO=$HOME/term (or wherever you put the compiled tree) in your 84 environment, then compile your source with tic. Tic and user programs 85 will check in $TERMINFO before looking in /usr/lib/terminfo/*/* 86 87 88 895 Philosophy in adding new terminfo capabilities: 90 91 Capabilities were cheap in termcap, since no code supported them 92 and they need only be documented. In terminfo, they add size to 93 the structure and the binaries, so don't add them in mass quantities. 94 95 Add a capability only if there is an application that wants to use it. 96 Lots of terminals have a half duplex forms editing mode, but no UNIX 97 applications use it, so we don't include it. 98 99 Before you add a capability, try to hold off until there are at least 100 2 or 3 different terminals implementing similar features. That way, 101 you can get a better idea of the general model that the capability 102 should have, rather than coming up with something that only works 103 on one kind of terminal. For example, the status line capabilities 104 were added after we had seen the h19, the tvi950, and the vt100 run 105 sysline. The original program, called h19sys, only worked on an h19 106 and addressed the cursor to line 25. This model doesn't fit other 107 terminals with a status line. 108 109 Note that capabilities must be added at the end of ../screen/caps. 110 Furthermore, if you add a private capability, you should check with 111 someone to make sure your capability goes into the master file, 112 otherwise someone else will add a different capability and 113 compatibility between two systems is destroyed. There must be one 114 master set of capabilities. This list is maintained at AT&T UNIX 115 Development. Comments should be sent to attunix!terminfo. 116 117 118 1196 Current murky areas include: 120 121 Color - there is demand for colors but it isn't clear what to do yet. 122 Some terminals support only 2 or 4 or 8 or 16 colors, others have a 123 palette of some huge selection. What are the standard colors? How 124 does graphics fit into this (terminfo is alphanumeric oriented?) 125 Curses can have another 16 bits added, or some routine set to decide 126 which 9 attribute bits have meaning in any given program. An 127 alternative is that if you just want color alphanumerics for a simple 128 application, e.g. highlighting certain fields, decide how you would 129 want your application to behave on a B/W terminal (e.g. a vt100), 130 using reverse for one thing, blinking for another, bold for another, 131 invisible for another, etc. 132 (Invis may be useful for colored fields with no information in them.) 133 Then make a terminfo entry with blink=xxx, bold=yyy, etc, where xxx 134 and yyy are sequences to go into the colors you really want. This way 135 your application also works on B/W terminals. 136 137 Graphics: Giles Billingsley at Berkeley did something called MFBCAP 138 once, it was like termcap but 3 times as big and handled graphics. 139 I don't think it was ever finished. I don't know how to do graphics 140 in curses, one might add it to terminfo at very high cost. 141 142 Input: things that send escape sequences to your program to be decoded 143 are a hard issue. You have to somehow deal with typeahead and with 144 terminals that can't do it. This includes "request cursor position", 145 for which a better solution is to immediately address the cursor to 146 a known position. (Curses also has filter mode that won't assume 147 the line but will assume the column.) Mice also fall into this 148 category. Scanf style strings (tparm is printf style) might be able 149 to decode these sequences, but I have no experience with them. 150 151 Alternate character set: the vt100 set seems to be becoming a defacto 152 standard, although it doesn't do much. I almost standardized on the 153 Teletype 5410, which was a nice superset of the vt100, but then Teletype 154 updated the 5410 to make it a vt100 duplicate, so now all I've put in 155 are the vt100 line drawing characters. HP has a more complete set, 156 but it has some really weird things in it and the mappings are 157 nonstandard. 158 Any extension should be able to handle both kinds of terminals, and 159 handle common programs without assuming an HP (or even a vt100). 160 161 ------------------------------------ 162 163 1647 Additional modules: 165 166 ckout shell script, analyzes file errs for diagnostics 167 and displays number of entries built 168 169 Doc.sed sed script to be run on ti files. 170 prints documentation of ti files. 171