Penguin
Recent Changes
Annotated edit history of tack(1) version 1, including all changes. View license author blame.
Rev Author # Line
1 perry 1 tack
2 !!!tack
3 NAME
4 SYNOPSIS
5 DESCRIPTION
6 OVERVIEW
7 CREATING NEW ENTRIES
8 VERIFYING AN EXISTING ENTRY
9 CORRECTING PAD TIMINGS
10 NOTE
11 FILES
12 SEE ALSO
13 BUGS
14 AUTHOR
15 ----
16 !!NAME
17
18
19 __tack__ - ''terminfo'' action checker
20 !!SYNOPSIS
21
22
23 __tack__ [[-itV] [[term]
24 !!DESCRIPTION
25
26
27 The __tack__ program has three purposes: (1) to help you
28 build a new terminfo entry describing an unknown terminal,
29 (2) to test the correctness of an existing entry, and (3) to
30 develop the correct pad timings needed to ensure that screen
31 updates don't fall behind the incoming data
32 stream.
33
34
35 __Tack__ presents a series of screen-painting and
36 interactive tests in ways which are intended to make any
37 mismatches between the terminfo entry and reality visually
38 obvious. __Tack__ also provides tools that can help in
39 understanding how the terminal operates.
40
41
42 __OPTIONS__
43
44
45 ''-i''
46
47
48 Usually __tack__ will send the reset and init strings to
49 the terminal when the program starts up. The ''-i''
50 option will inhibit the terminal
51 initialization.
52
53
54 ''-t''
55
56
57 Tell __tack__ to override the terminfo settings for basic
58 terminal functions. When this option is set __tack__ will
59 translate (cr) to r, (cud1) to n, (ind) to n, (nel) to rn,
60 (cub1) to b, (bel) to 007, (ff) to f and (ht) to
61 t.
62
63
64 ''-V''
65
66
67 Display the version information and exit.
68
69
70 ''term''
71
72
73 Terminfo terminal name to be tested. If not present then the
74 $TERM environment variable will be used.
75 !!OVERVIEW
76
77
78 Since __tack__ is designed to test terminfo's it is not
79 possible to rely on the correctness of the terminfo data
80 base. Because of this the menuing system used with
81 __tack__ is vary primitive. When a menu is printed it
82 will scroll the entire screen. To compensate for this
83 verbose menu system __tack__ permits menu selection type
84 ahead. If you already know what action you would like
85 __tack__ to perform then you can enter that value
86 immediately and avoid the menu display. When in doubt the
87 question mark (?) is a good character to type. A carriage
88 return will execute the default action. These default
89 actions are designed to run all the standard
90 tests.
91
92
93 When __tack__ first comes up it will display some basic
94 information about the terminal. Take some time to verify
95 this information. If it is wrong many of the subsequent
96 tests will fail. The most important item is the screen size.
97 If the screen size is wrong there is no point in proceeding.
98 (home) and (clear) are also critical to the success of
99 subsequent tests. The values of (cr) (ind) (cub1) and (ht)
100 may effect the tests if they are defined incorrectly. If
101 they are undefined __tack__ will set them to reasonable
102 defaults. The last two entries on the display are the
103 enquire and acknowledge strings. These strings are taken
104 from the user strings (u9) and (u8).
105
106
107 By now you must be wondering why the terminfo names are
108 enclosed in parenthesis. This has no profound meaning other
109 than it makes them stand out. The __tack__ program uses
110 this convention any time it displays a terminfo name.
111 Remember __tack__ is designed to rely on as little of the
112 terminfo entry as possible.
113 !!CREATING NEW ENTRIES
114
115
116 __Tack__ has a number of tools that are designed to help
117 gather information about the terminal. Although these
118 functions are not dependent on terminal type, you may wish
119 to execute __tack__ with options ''-it''. This will
120 turn off initialization and default the standard
121 entries.
122
123
124 These tools may be reached from the main menu by selecting
125 the 'tools' entry.
126
127
128 __Echo tool__: All data typed from the keyboard will be
129 echoed back to the terminal. Control characters are not
130 translated to the up arrow format but are sent as control
131 characters. This allows you to test an escape sequence and
132 see what it actually does. You may also elect to __enable
133 hex output on echo tool__ this will echo the characters in
134 hexadecimal. Once the test is running you may enter the
135 'lines' or 'columns' keywords which will display a pattern
136 that will help you determine your screen size. A complete
137 list of keywords will be displayed when the test starts.
138 Type 'help' to redisplay the list of available
139 commands.
140
141
142 __Reply tool__: This tool acts much like the echo tool,
143 but control characters that are sent from the terminal more
144 than one character after a carriage return will be expanded
145 to the up arrow format. For example on a standard ANSI
146 terminal you may type:
147
148
149 CR ESC [[ c
150
151
152 and the response will be echoed as something
153 like:
154
155
156 ^[[ [[ ? 6 c
157
158
159 __ANSI sgr display__: This test assumes you have an ANSI
160 terminal. It goes through attribute numbers 0 to 79,
161 displaying each in turn and using that SGR number to write
162 the text. This shows you which of the SGR modes are actually
163 implemented by the terminal. Note: some terminals (such as
164 Tektronix color) use the private use characters to augment
165 the functionality of the SGR command. These private use
166 characters may be interjected into the escape sequence by
167 typing the character (
168 __
169
170
171 __ANSI status reports__: This test queries the terminal
172 in standard ANSI/VT-100 fashion. The results of this test
173 may help determine what options are supported by your
174 terminal.
175
176
177 __ANSI character sets__: This test displays the character
178 sets available on a ANSI/VT-100 style terminal. Character
179 sets on a real VT-100 terminal are usually defined with
180 smacs=E(0 and rmacs=E(B. The first character after the
181 escape defines the font bank. The second character defines
182 the character set. This test allows you to view any of the
183 possible combinations. Private use character sets are
184 defined by the digits. Standard character sets are located
185 in the alphabetic range.
186 !!VERIFYING AN EXISTING ENTRY
187
188
189 You can verify the correctness of an entry with the `begin
190 testing' function. This entry is the default action and will
191 be chosen if you hit carriage return (or enter). This will
192 bring up a secondary menu that allows you to select more
193 specific tests.
194
195
196 The general philosophy of the program is, for each
197 capability, to send an appropriate test pattern to the
198 terminal then send a description of what the user should
199 expect. Occasionally (as when checking function-key
200 capabilities) the program will ask you to enter input for it
201 to check.
202
203
204 If the test fails then you have the option of dynamically
205 changing the terminfo entry and re-running the test. This is
206 done with the 'edit terminfo' menu item. The edit submenu
207 allows you to change the offending terminfo entry and
208 immediately retest the capability. The edit menu lets you do
209 other things with the terminfo, such as; display the entire
210 terminfo entry, display which caps have been tested and
211 display which caps cannot be tested. This menu also allows
212 you to write the newly modified terminfo to disc. If you
213 have made any modifications to the terminfo __tack__ will
214 ask you if you want to save the file to disc before it
215 exits. The filename will be the same as the terminal name.
216 After the program exits you can run the tic(1M) compiler on
217 the new terminfo to install it in the terminfo data
218 base.
219 !!CORRECTING PAD TIMINGS
220
221
222 __Theory of Overruns and Padding__
223
224
225 Some terminals require significant amounts of time (that is,
226 more than one transmitted-character interval) to do screen
227 updates that change large portions of the screen, such as
228 screen clears, line insertions, line deletions, and scrolls
229 (including scrolls triggered by line feeds or a write to the
230 lowest, right-hand-most cell of the screen).
231
232
233 If the computer continues to send characters to the terminal
234 while one of these time-consuming operations is going on,
235 the screen may be garbled. Since the length of a character
236 transmission time varies inversely with transmission speed
237 in cps, entries which function at lower speeds may break at
238 higher speeds.
239
240
241 Similar problems result if the host machine is simply
242 sending characters at a sustained rate faster than the
243 terminal can buffer and process them. In either case, when
244 the terminal cannot process them and can't tell the host to
245 stop soon enough, it will just drop them. The dropped
246 characters could be text, escape sequences or the escape
247 character itself, causing some really strange-looking
248 displays. This kind of glitch is called an
249 ''overrun''.
250
251
252 In terminfo entries, you can attach a __pad time__ to
253 each string capability that is a number of milliseconds to
254 delay after sending it. This will give the terminal time to
255 catch up and avoid overruns.
256
257
258 If you are running a software terminal emulator, or you are
259 on an X pseudo-tty, or your terminal is on an RS-232C line
260 which correctly handles RTS/CTS hardware flow control, then
261 pads are not strictly necessary. However, some display
262 packages (such as ncurses(3X)) use the pad counts to
263 calculate the fastest way to implement certain functions.
264 For example: scrolling the screen may be faster than
265 deleting the top line.
266
267
268 One common way to avoid overruns is with XON/XOFF
269 handshaking. But even this handshake may have problems at
270 high baud rates. This is a result of the way XON/XOFF works.
271 The terminal tells the host to stop with an XOFF. When the
272 host gets this character, it stops sending. However, there
273 is a small amount of time between the stop request and the
274 actual stop. During this window, the terminal must continue
275 to accept characters even though it has told the host to
276 stop. If the terminal sends the stop request too late, then
277 its internal buffer will overflow. If it sends the stop
278 character too early, then the terminal is not getting the
279 most efficient use out of its internal buffers. In a real
280 application at high baud rates, a terminal could get a dozen
281 or more characters before the host gets around to suspending
282 transmission. Connecting the terminal over a network will
283 make the problem much worse.
284
285
286 (RTS/CTS handshaking does not have this problem because the
287 UARTs are signal-connected and the
288
289
290 __Timing your terminal__
291
292
293 In order to get accurate timings from your terminal
294 __tack__ needs to know when the terminal has finished
295 processing all the characters that were sent. This requires
296 a different type of handshaking than the XON/XOFF that is
297 supported by most terminals. __Tack__ needs to send a
298 request to the terminal and wait for its reply. Many
299 terminals will respond with an ACK when they receive an ENQ.
300 This is the preferred method since the sequence is short.
301 ANSI/VT-100 style terminals can mimic this handshake with
302 the escape sequence that requests 'primary device
303 attributes'.
304
305
306 ESC [[ c
307
308
309 The terminal will respond with a sequence like:
310
311
312 ESC [[ ? 1 ; 0 c
313
314
315 __Tack__ assumes that (u9) is the enquire sequence and
316 that (u8) is the acknowledge string. A VT-100 style terminal
317 could set u9=E[[c and u8=E[[?1;0c. Acknowledge strings fall
318 into two categories. 1) Strings with a unique terminating
319 character and, 2) strings of fixed length. The acknowledge
320 string for the VT-100 is of the first type since it always
321 ends with the letter 'c'. Some Tektronics terminals have
322 fixed length acknowledge strings. __Tack__ supports both
323 types of strings by scanning for the terminating character
324 until the length of the expected acknowledge string has
325 arrived. (u8) should be set to some typical acknowledge that
326 will be returned when (u9) is sent.
327
328
329 __Tack__ will test this sequence before running any of
330 the pad tests or the function key tests. __Tack__ will
331 ask you the following:
332
333
334 Hit lower case g to start testing...
335
336
337 After it sends this message it will send the enquire string.
338 It will then read characters from the terminal until it sees
339 the letter g.
340
341
342 __Testing and Repairing Pad Timings__
343
344
345 The pad timings in distributed terminfo entries are often
346 incorrect. One major motivation for this program is to make
347 it relatively easy to tune these timings.
348
349
350 You can verify and edit the pad timings for a terminal with
351 the `test string capabilities' function (this is also part
352 of the `normal test sequence' function).
353
354
355 The key to determining pad times is to find out the
356 effective baud rate of the terminal. The effective baud rate
357 determines the number of characters per second that the
358 terminal can accept without either handshaking or losing
359 data. This rate is frequently less than the nominal cps rate
360 on the RS-232 line.
361
362
363 __Tack__ uses the effective baud rate to judge the
364 duration of the test and how much a particular escape
365 sequence will perturb the terminal.
366
367
368 Each pad test has two associated variables that can be
369 tweaked to help verify the correctness of the pad timings.
370 One is the pad test length. The other is the pad multiplier,
371 which is used if the pad prefix includes `*'. In curses use,
372 it is often the first parameter of the capability (if there
373 is one). For a capability like (dch) or (il) this will be
374 the number of character positions or lines affected,
375 respectively.
376
377
378 __Tack__ will run the pad tests and display the results
379 to the terminal. On capabilities that have multipliers
380 __tack__ will not tell you if the pad needs the
381 multiplier or not. You must make this decision yourself by
382 rerunning the test with a different multiplier. If the
383 padding changes in proportion to the multiplier than the
384 multiplier is required. If the multiplier has little or no
385 effect on the suggested padding then the multiplier is not
386 needed. Some capabilities will take several runs to get a
387 good feel for the correct values. You may wish to make the
388 test longer to get more accurate results. System load will
389 also effect the results (a heavily loaded system will not
390 stress the terminal as much, possibly leading to pad timings
391 that are too short).
392 !!NOTE
393
394
395 The tests done at the beginning of the program are assumed
396 to be correct later in the code. In particular, __tack__
397 displays the number of lines and columns indicated in the
398 terminfo entry as part of its initial output. If these
399 values are wrong a large number of tests will fail or give
400 incorrect results.
401 !!FILES
402
403
404 tack.log
405
406
407 If logging is enabled then all characters written to the
408 terminal will also be written to the log file. This gives
409 you the ability to see how the tests were performed. This
410 feature is disabled by default.
411
412
413 ''term'' If you make changes to the terminfo entry
414 __tack__ will save the new terminfo to a file. The file
415 will have the same name as the terminal name.
416 !!SEE ALSO
417
418
419 terminfo(5), __ncurses__(3X), tic(1m),
420 infocmp(1m). You should also have the documentation
421 supplied by the terminal manufacturer.
422 !!BUGS
423
424
425 If the screen size is incorrect, many of the tests will
426 fail.
427 !!AUTHOR
428
429
430 Concept, design, and original implementation by Daniel
431 Weaver
432 ----
This page is a man page (or other imported legacy content). We are unable to automatically determine the license status of this page.