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