tack - terminfo action checker


   tack [-itV] [term]


   The  tack  program  has  three  purposes:  (1)  to help you build a new
   terminfo  entry  describing  an  unknown  terminal,  (2)  to  test  the
   correctness  of  an  existing entry, and (3) to develop the correct pad
   timings needed to ensure that screen  updates  don't  fall  behind  the
   incoming data stream.

   Tack presents a series of screen-painting and interactive tests in ways
   which are intended to make any mismatches between  the  terminfo  entry
   and  reality  visually obvious.  Tack also provides tools that can help
   in understanding how the terminal operates.

   -i     Usually tack will  send  the  reset  and  init  strings  to  the
          terminal when the program starts up.  The -i option will inhibit
          the terminal initialization.

   -t     Tell tack to override the terminfo settings for  basic  terminal
          functions.   When this option is set tack will translate (cr) to
          \r, (cud1) to \n, (ind) to \n, (nel)  to  \r\n,  (cub1)  to  \b,
          (bel) to \007, (ff) to \f and (ht) to \t.

   -V     Display the version information and exit.

   term   Terminfo  terminal  name  to be tested.  If not present then the
          $TERM environment variable will be used.


   Since tack is designed to test terminfo's it is not possible to rely on
   the correctness of the terminfo data base.  Because of this the menuing
   system used with tack is vary primitive.  When a  menu  is  printed  it
   will  scroll  the  entire  screen.  To compensate for this verbose menu
   system tack permits menu selection type ahead.   If  you  already  know
   what  action  you  would  like  tack to perform then you can enter that
   value immediately and avoid  the  menu  display.   When  in  doubt  the
   question  mark (?) is a good character to type.  A carriage return will
   execute the default action.  These default actions are designed to  run
   all the standard tests.

   When  tack  first comes up it will display some basic information about
   the terminal.  Take some time to verify this  information.   If  it  is
   wrong  many of the subsequent tests will fail.  The most important item
   is the screen size.  If the screen size is wrong there is no  point  in
   proceeding.   (home)  and  (clear)  are also critical to the success of
   subsequent tests.  The values of (cr) (ind) (cub1) and (ht) may  effect
   the  tests if they are defined incorrectly.  If they are undefined tack
   will set them to reasonable defaults.  The  last  two  entries  on  the
   display  are  the  enquire  and acknowledge strings.  These strings are
   taken from the user strings (u9) and (u8).

   By now you must be wondering why the terminfo  names  are  enclosed  in
   parenthesis.   This  has  no  profound meaning other than it makes them
   stand out.  The tack program uses this convention any time it  displays
   a terminfo name.  Remember tack is designed to rely on as little of the
   terminfo entry as possible.


   Tack has a number of tools that are designed to help gather information
   about  the  terminal.   Although  these  functions are not dependent on
   terminal type, you may wish to execute tack  with  options  -it.   This
   will turn off initialization and default the standard entries.

   These  tools may be reached from the main menu by selecting the 'tools'

   Echo tool:  All data typed from the keyboard will be echoed back to the
   terminal.  Control characters are not translated to the up arrow format
   but are sent as control characters.  This allows you to test an  escape
   sequence  and  see what it actually does.  You may also elect to enable
   hex output on echo tool this will echo the characters  in  hexadecimal.
   Once  the  test  is  running  you  may  enter  the 'lines' or 'columns'
   keywords which will display a pattern that will help you determine your
   screen  size.   A  complete list of keywords will be displayed when the
   test starts.  Type 'help' to redisplay the list of available commands.

   Reply tool:  This tool acts  much  like  the  echo  tool,  but  control
   characters  that  are  sent  from  the terminal more than one character
   after a carriage return will be expanded to the up arrow  format.   For
   example on a standard ANSI terminal you may type:

             CR ESC [ c

   and the response will be echoed as something like:

             ^[ [ ? 6 c

   ANSI  sgr  display:   This  test assumes you have an ANSI terminal.  It
   goes through attribute numbers 0 to 79, displaying  each  in  turn  and
   using  that  SGR number to write the text.  This shows you which of the
   SGR modes  are  actually  implemented  by  the  terminal.   Note:  some
   terminals  (such  as Tektronix color) use the private use characters to
   augment the functionality  of  the  SGR  command.   These  private  use
   characters  may  be  interjected into the escape sequence by typing the
   character ( <, =, >, ? ) after the original display has been shown.

   ANSI status reports:   This  test  queries  the  terminal  in  standard
   ANSI/VT-100  fashion.  The results of this test may help determine what
   options are supported by your terminal.

   ANSI character sets:  This test displays the character  sets  available
   on  a  ANSI/VT-100  style  terminal.   Character  sets on a real VT-100
   terminal are usually defined with smacs=\E(0 and rmacs=\E(B.  The first
   character after the escape defines the font bank.  The second character
   defines the character set.  This test allows you to  view  any  of  the
   possible  combinations.   Private use character sets are defined by the
   digits.  Standard character sets are located in the alphabetic range.


   You can verify the correctness of an entry  with  the  `begin  testing'
   function.   This  entry is the default action and will be chosen if you
   hit carriage return (or enter).  This will bring up  a  secondary  menu
   that allows you to select more specific tests.

   The  general philosophy of the program is, for each capability, to send
   an appropriate test pattern to the terminal then send a description  of
   what  the user should expect.  Occasionally (as when checking function-
   key capabilities) the program will ask you to enter  input  for  it  to

   If  the test fails then you have the option of dynamically changing the
   terminfo entry and re-running the test.  This is done  with  the  'edit
   terminfo'  menu  item.   The  edit  submenu  allows  you  to change the
   offending terminfo entry and immediately retest  the  capability.   The
   edit  menu lets you do other things with the terminfo, such as; display
   the entire terminfo entry, display which  caps  have  been  tested  and
   display  which  caps  cannot  be  tested.  This menu also allows you to
   write the newly modified terminfo  to  disc.   If  you  have  made  any
   modifications to the terminfo tack will ask you if you want to save the
   file to disc before it exits.  The filename will be  the  same  as  the
   terminal  name.   After  the  program  exits  you  can  run the tic(1M)
   compiler on the new terminfo to install it in the terminfo data base.


   Theory of Overruns and Padding
   Some terminals require significant amounts of time (that is, more  than
   one  transmitted-character  interval)  to do screen updates that change
   large portions of the screen, such as screen clears,  line  insertions,
   line  deletions, and scrolls (including scrolls triggered by line feeds
   or a write to the lowest, right-hand-most cell of the screen).

   If the computer continues to send characters to the terminal while  one
   of  these  time-consuming  operations  is  going  on, the screen may be
   garbled.  Since the length of  a  character  transmission  time  varies
   inversely  with  transmission  speed  in cps, entries which function at
   lower speeds may break at higher speeds.

   Similar  problems  result  if  the  host  machine  is  simply   sending
   characters  at a sustained rate faster than the terminal can buffer and
   process them.  In either case, when the terminal  cannot  process  them
   and  can't  tell  the host to stop soon enough, it will just drop them.
   The dropped characters could be text, escape sequences  or  the  escape
   character  itself,  causing some really strange-looking displays.  This
   kind of glitch is called an overrun.

   In terminfo  entries,  you  can  attach  a  pad  time  to  each  string
   capability  that is a number of milliseconds to delay after sending it.
   This will give the terminal time to catch up and avoid overruns.

   If you are running a software terminal emulator, or you  are  on  an  X
   pseudo-tty,  or  your  terminal  is  on an RS-232C line which correctly
   handles RTS/CTS hardware flow  control,  then  pads  are  not  strictly
   necessary.   However,  some  display packages (such as ncurses(3X)) use
   the pad counts to  calculate  the  fastest  way  to  implement  certain
   functions.   For  example:  scrolling  the  screen  may  be faster than
   deleting the top line.

   One common way to avoid overruns is  with  XON/XOFF  handshaking.   But
   even  this  handshake  may have problems at high baud rates.  This is a
   result of the way XON/XOFF works.  The terminal tells the host to  stop
   with  an  XOFF.   When  the host gets this character, it stops sending.
   However, there is a small amount of time between the stop  request  and
   the  actual  stop.   During  this window, the terminal must continue to
   accept characters even though it has told the host  to  stop.   If  the
   terminal sends the stop request too late, then its internal buffer will
   overflow.  If it sends the stop character too early, then the  terminal
   is  not getting the most efficient use out of its internal buffers.  In
   a real application at high baud rates, a terminal could get a dozen  or
   more characters before the host gets around to suspending transmission.
   Connecting the terminal over a  network  will  make  the  problem  much

   (RTS/CTS  handshaking  does not have this problem because the UARTs are
   signal-connected and the "stop flow"  is  done  at  the  lowest  level,
   without software intervention).

   Timing your terminal
   In  order to get accurate timings from your terminal tack needs to know
   when the terminal has finished processing all the characters that  were
   sent.   This requires a different type of handshaking than the XON/XOFF
   that is supported by most terminals.  Tack needs to send a  request  to
   the  terminal and wait for its reply.  Many terminals will respond with
   an ACK when they receive an ENQ.  This is the  preferred  method  since
   the  sequence  is  short.   ANSI/VT-100  style terminals can mimic this
   handshake with  the  escape  sequence  that  requests  'primary  device

      ESC [ c

   The terminal will respond with a sequence like:

      ESC [ ? 1 ; 0 c

   Tack  assumes  that  (u9)  is the enquire sequence and that (u8) is the
   acknowledge string.  A VT-100 style  terminal  could  set  u9=\E[c  and
   u8=\E[?1;0c.  Acknowledge strings fall into two categories.  1) Strings
   with a unique terminating character and, 2) strings  of  fixed  length.
   The  acknowledge  string  for  the VT-100 is of the first type since it
   always ends with the letter 'c'.  Some Tektronics terminals have  fixed
   length  acknowledge  strings.   Tack  supports both types of strings by
   scanning for the terminating character until the length of the expected
   acknowledge  string  has  arrived.   (u8) should be set to some typical
   acknowledge that will be returned when (u9) is sent.

   Tack will test this sequence before running any of the pad tests or the
   function key tests.  Tack will ask you the following:

       Hit lower case g to start testing...

   After  it  sends this message it will send the enquire string.  It will
   then read characters from the terminal until it sees the letter g.

   Testing and Repairing Pad Timings
   The pad timings in distributed terminfo entries  are  often  incorrect.
   One  major motivation for this program is to make it relatively easy to
   tune these timings.

   You can verify and edit the pad timings for a terminal with  the  `test
   string  capabilities'  function  (this is also part of the `normal test
   sequence' function).

   The key to determining pad times is to find out the effective baud rate
   of  the  terminal.   The  effective  baud rate determines the number of
   characters per second that  the  terminal  can  accept  without  either
   handshaking  or  losing  data.   This  rate is frequently less than the
   nominal cps rate on the RS-232 line.

   Tack uses the effective baud rate to judge the duration of the test and
   how much a particular escape sequence will perturb the terminal.

   Each  pad test has two associated variables that can be tweaked to help
   verify the correctness of the pad timings.  One is the pad test length.
   The  other  is  the  pad  multiplier,  which  is used if the pad prefix
   includes `*'.  In curses use, it is often the first  parameter  of  the
   capability (if there is one).  For a capability like (dch) or (il) this
   will  be  the  number  of  character  positions  or   lines   affected,

   Tack  will  run  the pad tests and display the results to the terminal.
   On capabilities that have multipliers tack will not tell you if the pad
   needs  the  multiplier or not.  You must make this decision yourself by
   rerunning the test with a different multiplier.  If the padding changes
   in  proportion  to  the multiplier than the multiplier is required.  If
   the multiplier has little or no effect on the  suggested  padding  then
   the multiplier is not needed.  Some capabilities will take several runs
   to get a good feel for the correct values.  You may wish  to  make  the
   test longer to get more accurate results.  System load will also effect
   the results (a heavily loaded system will not stress  the  terminal  as
   much, possibly leading to pad timings that are too short).


   The  tests  done  at  the  beginning  of  the program are assumed to be
   correct later in the code.  In particular, tack displays the number  of
   lines  and  columns  indicated  in  the  terminfo  entry as part of its
   initial output.  If these values are wrong a large number of tests will
   fail or give incorrect results.


   tack.log    If  logging  is  enabled then all characters written to the
               terminal will also be written to the log file.  This  gives
               you  the ability to see how the tests were performed.  This
               feature is disabled by default.

   term        If you make changes to the terminfo entry  tack  will  save
               the  new  terminfo  to a file.  The file will have the same
               name as the terminal name.


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


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


   Concept,   design,   and   original  implementation  by  Daniel  Weaver
   <danw@znyx.com>.  Portions of the code and documentation are by Eric S.
   Raymond <esr@snark.thyrsus.com>.


More Linux Commands

pcre16_free_substring(3) Perl-compatible regular expressions
This is a convenience function for freeing the store obtained by a previous call to pcre[16|32]_get_substring() or pcre[16|32]_get_named_substring(). Its only a

ssignal(3) - software signal facility - Linux manual page...
Dont use these functions under Linux. Due to a historical mistake, under Linux these functions are aliases for raise(3) and signal(2), respectively. Elsewhere,

asctime(3) - transform date and time to broken-down time or
The ctime(), gmtime() and localtime() functions all take an argument of data type time_t, which represents calendar time. When interpreted as an absolute time v

qfcvt(3) - convert a floating-point number to a string......
The functions qecvt(), qfcvt() and qgcvt() are identical to ecvt(3), fcvt(3) and gcvt(3) respectively, except that they use a long double argument number. See e

kismet(1) Wireless sniffing and monitoring - Linux man page
Kismet is an 802.11 layer2 wireless network detector, sniffer, and intrusion detection system. Kismet will work with any wireless card which supports raw monito

ldap_strdup(3) - LDAP memory allocation routines (Man Page)
These routines are used to allocate/deallocate memory used/returned by the LDAP library. ldap_memalloc(), ldap_memcalloc(), ldap_memrealloc(), and ldap_memfree(

ping6(8) - send ICMP ECHO_REQUEST to network hosts (ManPage)
ping uses the ICMP protocols mandatory ECHO_REQUEST datagram to elicit an ICMP ECHO_RESPONSE from a host or gateway. ECHO_REQUEST datagrams (pings) have an IP a

strcoll(3) - compare two strings using the current locale...
The strcoll() function compares the two strings s1 and s2. It returns an integer less than, equal to, or greater than zero if s1 is found, respectively, to be l

lockfile(1) - conditional semaphore-file creator (Man Page)
lockfile can be used to create one or more semaphore files. If lockfile cant create all the specified files (in the specified order), it waits sleeptime (defaul

request_key(2) - Request a key from the kernel's key managem
request_key() asks the kernel to find a key of the given type that matches the specified description and, if successful, to attach it to the nominated keyring a

podchecker(1) - check the syntax of POD format documentation
podchecker will read the given input files looking for POD syntax errors in the POD documentation and will print any errors it find to STDERR. At the end, it wi

getspent_r(3) - get shadow password file entry (Man Page)...
Long ago it was considered safe to have encrypted passwords openly visible in the password file. When computers got faster and people got more security-consciou

We can't live, work or learn in freedom unless the software we use is free.