1tack(1)                     General Commands Manual                    tack(1)
2
3
4

NAME

6       tack - terminfo action checker
7

SYNOPSIS

9       tack [-diltV] [term]
10

DESCRIPTION

12       The tack program has three purposes:
13
14       (1) to help you build a new terminfo entry describing an unknown termi‐
15           nal,
16
17       (2) to test the correctness of an existing entry, and
18
19       (3) to develop the correct pad timings needed to ensure that screen up‐
20           dates do not fall behind the incoming data stream.
21
22       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
27   OPTIONS
28       -d     Start tack with the debug-file “debug.log” opened.
29
30       -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
34       -l     Start tack with the log-file “tack.log” opened.  This is also  a
35              menu item.
36
37       -t     Tell  tack  to override the terminfo settings for basic terminal
38              functions.  When this option is set, tack will translate
39
40              (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
49       -V     Display the version information and exit.
50
51       term   Terminfo terminal name to be tested.  If not present,  then  the
52              $TERM environment variable will be used.
53

OVERVIEW

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,
57       the  menuing  system  used with tack is very 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 al‐
60       ready know what action you would like tack to perform then you can  en‐
61       ter  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
66       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
77       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

CREATING NEW ENTRIES

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
89       These tools may be reached from the main menu by selecting the  “tools”
90       entry.
91
92       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
102       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
107                 CR ESC [ c
108
109       and the response will be echoed as something like:
110
111                 ^[ [ ? 6 c
112
113       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 us‐
115       ing that SGR number to write the text.  This shows you which of the SGR
116       modes  are  actually implemented by the terminal.  Note: some terminals
117       (such as Tektronix color) use the private use characters to augment the
118       functionality  of the SGR command.  These private use characters may be
119       interjected into the escape sequence by typing the character ( <, =, >,
120       ? ) after the original display has been shown.
121
122       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
126       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

VERIFYING AN EXISTING ENTRY

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
140       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
146       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 be‐
155       fore  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

CORRECTING PAD TIMINGS

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
167       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 in‐
170       versely with transmission speed in cps, entries which function at lower
171       speeds may break at higher speeds.
172
173       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
181       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
185       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
193       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 ac‐
199       cept  characters even though it has told the host to stop.  If the ter‐
200       minal 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
208       (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
212   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 at‐
221       tributes”.
222
223          ESC [ c
224
225       The terminal will respond with a sequence like:
226
227          ESC [ ? 1 ; 0 c
228
229       Tack assumes that (u9) is the enquire sequence and that (u8) is the ac‐
230       knowledge  string.   A  VT-100  style  terminal  could  set u9=\E[c and
231       u8=\E[?1;0c.  Acknowledge strings fall into two categories.
232
233       1)  Strings with a unique terminating character and,
234
235       2)  strings of fixed length.
236
237       The acknowledge string for the VT-100 is of the first type since it al‐
238       ways  ends  with  the  letter “c”.  Some Tektronix 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 ac‐
242       knowledge that will be returned when (u9) is sent.
243
244       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
247           Hit lower case g to start testing...
248
249       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
252   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
257       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
261       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
267       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
270       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  in‐
273       cludes  “*”.  In curses use, it is often the first parameter of the ca‐
274       pability (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
278       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

NOTE

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

FILES

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
303       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

SEE ALSO

308       terminfo(5),  ncurses(3X),  tic(1M), infocmp(1M).  You should also have
309       the documentation supplied by the terminal manufacturer.
310

BUGS

312       If the screen size is incorrect, many of the tests will fail.
313

AUTHOR

315       Concept, design, and original implementation by Daniel Weaver
316       <dan.weaver@znyx.com>.
317
318       Portions of the code and documentation are by Eric S. Raymond
319       <esr@snark.thyrsus.com>.
320
321       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
325
326
327                                                                       tack(1)
Impressum