]> ncurses.scripts.mit.edu Git - ncurses.git/blob - tack/tack.1
ncurses 5.0
[ncurses.git] / tack / tack.1
1 .TH tack 1M ""
2 .ds n 5
3 .ds d @TERMINFO@
5 \fBtack\fR - \fIterminfo\fR action checker
7 \fBtack\fR [-itV] [term]
8 .br
10 The \fBtack\fR program has three purposes:
11 (1) to help you build a new terminfo entry describing an unknown terminal,
12 (2) to test the correctness of an existing entry, and
13 (3) to develop the correct pad timings needed to ensure that screen updates
14 don't fall behind the incoming data stream.
15 .PP
16 \fBTack\fR presents a series of screen-painting and interactive
17 tests in ways which are intended to make any mismatches between the
18 terminfo entry and reality visually obvious. 
19 \fBTack\fR also provides tools that can help in understanding how
20 the terminal operates.
22 .TP
23 .I "\-i"
24 Usually \fBtack\fR will send the reset and init strings to the terminal
25 when the program starts up.  The \fI-i\fR option will inhibit the
26 terminal initialization.
27 .TP
28 .I "\-t"
29 Tell \fBtack\fR to override the terminfo settings for basic terminal
30 functions.  When this option is set \fBtack\fR will translate
31 (cr) to \\r, (cud1) to \\n, (ind) to \\n, (nel) to \\r\\n,
32 (cub1) to \\b, (bel) to \\007, (ff) to \\f and (ht) to \\t.
33 .TP
34 .I "\-V"
35 Display the version information and exit.
36 .TP
37 .I "term"
38 Terminfo terminal name to be tested.  If not present then the $TERM
39 environment variable will be used.
41 Since \fBtack\fR is designed to test terminfo's it is not possible
42 to rely on the correctness of the terminfo data base.  Because of this
43 the menuing system used with \fBtack\fR is vary primitive.  When a
44 menu is printed it will scroll the entire screen.  To compensate
45 for this verbose menu system \fBtack\fR permits menu selection
46 type ahead.
47 If you already know what action you would like \fBtack\fR to perform
48 then you can enter that value immediately and avoid the menu display.
49 When in doubt the question mark (?) is a good character to type.
50 A carriage return will execute the default action.  These default
51 actions are designed to run all the standard tests.
52 .PP
53 When \fBtack\fR first comes up it will display some basic information
54 about the terminal.  Take some time to verify this information.
55 If it is wrong many of the subsequent tests will fail.  The most
56 important item is the screen size.  If the screen size is wrong there
57 is no point in proceeding.  (home) and (clear) are also critical
58 to the success of subsequent tests.  The values of (cr) (ind)
59 (cub1) and (ht) may effect the tests if they are defined incorrectly.
60 If they are undefined \fBtack\fR will set them to reasonable defaults.
61 The last two entries on the display are the enquire and acknowledge strings.
62 These strings are taken from the user strings (u9) and (u8).
63 .PP
64 By now you must be wondering why the terminfo names are enclosed
65 in parenthesis.  This has no profound meaning other than it makes
66 them stand out.  The \fBtack\fR program uses this convention any time
67 it displays a terminfo name.  Remember \fBtack\fR is designed to
68 rely on as little of the terminfo entry as possible.
70 \fBTack\fR has a number of tools that are designed to help gather
71 information about the terminal.  Although these functions are not
72 dependent on terminal type, you may wish to execute \fBtack\fR
73 with options \fI\-it\fR.  This will turn off initialization
74 and default the standard entries.
75 .PP
76 These tools may be reached from the main menu by selecting
77 the 'tools' entry.
78 .PP
79 \fBEcho tool\fR:  All data typed from the keyboard will be echoed back
80 to the terminal.  Control characters are not translated to the up arrow format
81 but are sent as control characters.  This allows you to test an escape
82 sequence and see what it actually does.  You may also elect to
83 \fBenable hex output on echo tool\fR this will echo the characters in
84 hexadecimal.  Once the test is running you may enter the 'lines'
85 or 'columns' keywords which will display a pattern that will help
86 you determine your screen size.  A complete list of keywords will
87 be displayed when the test starts.  Type 'help' to redisplay
88 the list of available commands.
89 .PP
90 \fBReply tool\fR:  This tool acts much like the echo tool, but
91 control characters that are sent from the terminal more than one character
92 after a carriage return will be expanded to the up arrow format.  For example
93 on a standard ANSI terminal you may type:
95                 CR ESC [ c
97 and the response will be echoed as something like:
99                 ^[ [ ? 6 c
100 .PP
101 \fBANSI sgr display\fR:  This test assumes you have an ANSI terminal.  It
102 goes through attribute numbers 0 to 79, displaying each in turn and using that
103 SGR number to write the text.  This shows you which of the SGR
104 modes are actually implemented by the terminal.  Note: some terminals (such as
105 Tektronix color) use the private use characters to augment the functionality of
106 the SGR command.  These private use characters may be interjected into the
107 escape sequence by typing the character ( <, =, >, ? ) after the original
108 display has been shown.
109 .PP
110 \fBANSI status reports\fR:  This test queries the terminal in standard
111 ANSI/VT-100 fashion.  The results of this test may help
112 determine what options are supported by your terminal.
113 .PP
114 \fBANSI character sets\fR:  This test displays the character sets
115 available on a ANSI/VT-100 style terminal.
116 Character sets on a real VT-100 terminal are usually defined
117 with smacs=\\E(0 and rmacs=\\E(B.  The first character after the
118 escape defines the font bank.  The second character defines the
119 character set.  This test allows you to view any of the possible
120 combinations.  Private use character sets are defined by the digits.
121 Standard character sets are located in the alphabetic range.
123 .PP
124 You can verify the correctness of an entry with the `begin testing'
125 function.  This entry is the default action and will be chosen
126 if you hit carriage return (or enter).  This will bring up a
127 secondary menu that allows you to select more specific tests.
128 .PP
129 The general philosophy of the program is, for each capability, to send an
130 appropriate test pattern to the terminal then send a description of
131 what the user should expect.  Occasionally (as when checking function-key
132 capabilities) the program will ask you to enter input for it to check.
133 .PP
134 If the test fails then you have the option of dynamically changing
135 the terminfo entry and re-running the test.  This is done with
136 the 'edit terminfo' menu item.  The edit submenu allows you to change
137 the offending terminfo entry and immediately retest the capability.
138 The edit menu lets you do other things with the terminfo, such as;
139 display the entire terminfo entry,
140 display which caps have been tested and display which caps cannot
141 be tested.  This menu also allows you to write the newly modified
142 terminfo to disc.  If you have made any modifications to the
143 terminfo \fBtack\fR will ask you if you want to save the file
144 to disc before it exits.  The filename will be the same as the terminal name.
145 After the program exits you can run the tic(1M) compiler on the
146 new terminfo to install it in the terminfo data base.
147 .PP
149 .SS Theory of Overruns and Padding
150 .PP
151 Some terminals require significant amounts of time (that is, more than one
152 transmitted-character interval) to do screen updates that change large
153 portions of the screen, such as screen clears, line insertions,
154 line deletions, and scrolls (including scrolls triggered by line feeds
155 or a write to the lowest, right-hand-most cell of the screen).
156 .PP
157 If the computer continues to send characters to the terminal while one
158 of these time-consuming operations is going on, the screen may be garbled.
159 Since the length of a character transmission time varies inversely with
160 transmission speed in cps, entries which function at lower speeds may
161 break at higher speeds.
162 .PP
163 Similar problems result if the host machine is simply sending characters at a
164 sustained rate faster than the terminal can buffer and process them.  In either
165 case, when the terminal cannot process them and can't tell the host to stop
166 soon enough, it will just drop them.  The dropped characters could be text,
167 escape sequences or the escape character itself, causing some really
168 strange-looking displays.  This kind of glitch is called an \fIoverrun\fR.
169 .PP
170 In terminfo entries, you can attach a \fBpad time\fR to each string capability
171 that is a number of milliseconds to delay after sending it.  This will give
172 the terminal time to catch up and avoid overruns.
173 .PP
174 If you are running a software terminal emulator, or you are on an X pseudo-tty,
175 or your terminal is on an RS-232C line which correctly handles RTS/CTS
176 hardware flow control, then pads are not strictly necessary.  However, some
177 display packages (such as ncurses(3X)) use the pad counts to calculate
178 the fastest way to implement certain functions.
179 For example: scrolling the screen may be faster than deleting the top line.
180 .PP
181 One common way to avoid overruns is with XON/XOFF handshaking.
182 But even this handshake may have problems at high baud rates.
183 This is a result of the way XON/XOFF works.  The terminal tells
184 the host to stop with an XOFF.  When the host gets this character, it stops
185 sending.  However, there is a small amount of time between the stop request and
186 the actual stop.  During this window, the terminal must continue to accept
187 characters even though it has told the host to stop.  If the terminal sends
188 the stop request too late, then its internal buffer will overflow.  If it sends
189 the stop character too early, then the terminal is not getting the most
190 efficient use out of its internal buffers.  In a real application at high baud
191 rates, a terminal could get a dozen or more characters before the host gets
192 around to suspending transmission.  Connecting the terminal over a network
193 will make the problem much worse.
194 .PP
195 (RTS/CTS handshaking does not have this problem because the UARTs are
196 signal-connected and the "stop flow" is done at the lowest level, without
197 software intervention).
198 .PP
199 .SS Timing your terminal
200 .PP
201 In order to get accurate timings from your terminal \fBtack\fR 
202 needs to know when the terminal has finished processing all the
203 characters that were sent.  This requires a different type of handshaking
204 than the XON/XOFF that is supported by most terminals.  \fBTack\fR
205 needs to send a request to the terminal and wait for its reply.
206 Many terminals will respond with an ACK when they receive an ENQ.
207 This is the preferred method since the sequence is short.
208 ANSI/VT-100 style terminals can mimic this handshake with the
209 escape sequence that requests 'primary device attributes'.
211    ESC [ c
213 The terminal will respond with a sequence like:
215    ESC [ ? 1 ; 0 c
217 \fBTack\fR assumes that (u9) is the enquire sequence and that (u8) is the
218 acknowledge string.  A VT-100 style terminal could set u9=\\E[c
219 and u8=\\E[?1;0c.
220 Acknowledge strings fall into two categories. 
221 1) Strings with a unique terminating character and,
222 2) strings of fixed length.
223 The acknowledge string for the VT-100 is of the first type since
224 it always ends with the letter 'c'.  Some Tektronics terminals
225 have fixed length acknowledge strings.  \fBTack\fR supports both
226 types of strings by scanning for the terminating character until
227 the length of the expected acknowledge string has arrived.
228 (u8) should be set to some typical acknowledge that will be
229 returned when (u9) is sent.
230 .PP
231 \fBTack\fR will test this sequence before running any of the pad
232 tests or the function key tests.  \fBTack\fR will ask you the following:
234     Hit lower case g to start testing...
236 After it sends this message it will send the enquire string.
237 It will then read characters from the terminal until it sees the
238 letter g.
239 .PP
240 .SS Testing and Repairing Pad Timings
241 .PP
242 The pad timings in distributed terminfo entries are often incorrect.  One
243 major motivation for this program is to make it relatively easy to tune these
244 timings.
245 .PP
246 You can verify and edit the pad timings for a terminal with
247 the `test string capabilities'
248 function (this is also part of the `normal test sequence' function).
249 .PP
250 The key to determining pad times is to find out the effective baud rate of
251 the terminal.  The effective baud rate determines the number of characters
252 per second that the terminal can accept without either handshaking or
253 losing data.  This rate is frequently less than the nominal cps rate on the
254 RS-232 line.
255 .PP
256 \fBTack\fR uses the effective baud rate to judge the duration of the test and
257 how much a particular escape sequence will perturb the terminal.
258 .PP
259 Each pad test has two associated variables that can be tweaked to help verify
260 the correctness of the pad timings.  One is the pad test length.  The other is
261 the pad multiplier, which is used if the pad prefix includes `*'.  In curses
262 use, it is often the first parameter of the capability (if there is one).
263 For a capability like (dch) or (il) this will be the number of character
264 positions or lines affected, respectively.
265 .PP
266 \fBTack\fR will run the pad tests and display the results to the terminal.
267 On capabilities that have multipliers \fBtack\fR will not tell you
268 if the pad needs the multiplier or not.  You must make this decision
269 yourself by rerunning the test with a different multiplier.
270 If the padding changes in proportion to the multiplier than the
271 multiplier is required.  If the multiplier has little or no effect on
272 the suggested padding then the multiplier is not needed.
273 Some capabilities will take several runs to get a good feel for
274 the correct values.  You may wish to make the test longer
275 to get more accurate results.  System load will also effect the
276 results (a heavily loaded system will not stress the
277 terminal as much, possibly leading to pad timings that are too short).
278 .PP
279 .SH NOTE
280 The tests done at the beginning of the program are assumed to be correct later
281 in the code.  In particular, \fBtack\fR displays the number of lines and
282 columns indicated in the terminfo entry as part of its initial output.
283 If these values are wrong a large number of tests will fail or give incorrect
284 results.
286 .TP 12
287 tack.log
288 If logging is enabled then all characters written to the terminal
289 will also be written to the log file.  This gives you the ability
290 to see how the tests were performed.  This feature is disabled by default.
291 .TP 12
292 .I "term"
293 If you make changes to the terminfo entry \fBtack\fR will save
294 the new terminfo to a file.  The file will have the same name
295 as the terminal name.
297 \fBterminfo\fR(\*n), \fBncurses\fR(3X), \fBtic\fR(1m), \fBinfocmp\fR(1m).
298 You should also have the documentation supplied by the terminal
299 manufacturer.
300 .SH BUGS
301 If the screen size is incorrect, many of the tests will fail.
303 Concept, design, and original implementation by
304 Daniel Weaver <danw@znyx.com>.  Portions of the code and
305 documentation are by Eric S. Raymond <esr@snark.thyrsus.com>.
306 .\"#
307 .\"# The following sets edit modes for GNU EMACS
308 .\"# Local Variables:
309 .\"# mode:nroff
310 .\"# fill-column:79
311 .\"# End: