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 |
|
26 1 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 |
|
39 2 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 |
|
47 3 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 |
|
70 3 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 |
|
81 4 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 |
|
89 5 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 |
|
119 6 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 |
|
164 7 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. |
|