version 1 showing authors affecting page license.
.
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 |
---- |