Welcome to Linux Knowledge Base and Tutorial
"The place where you learn linux"
Mercy Corps

 Create an AccountHome | Submit News | Your Account  

Tutorial Menu
Linux Tutorial Home
Table of Contents

· Introduction to Operating Systems
· Linux Basics
· Working with the System
· Shells and Utilities
· Editing Files
· Basic Administration
· The Operating System
· The X Windowing System
· The Computer Itself
· Networking
· System Monitoring
· Solving Problems
· Security
· Installing and Upgrading
· Linux and Windows

Glossary
MoreInfo
Man Pages
Linux Topics
Test Your Knowledge

Site Menu
Site Map
FAQ
Copyright Info
Terms of Use
Privacy Info
Disclaimer
WorkBoard
Thanks
Donations
Advertising
Masthead / Impressum
Your Account

Communication
Feedback
Forums
Private Messages
Surveys

Features
HOWTOs
News Archive
Submit News
Topics
User Articles
Web Links

Google
Google


The Web
linux-tutorial.info

Who's Online
There are currently, 42 guest(s) and 0 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here

  

tack



SYNOPSIS

       tack [-itV] [term]


DESCRIPTION

       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.

   OPTIONS
       -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  pre­
              sent  then  the  $TERM environment variable will be
              used.


OVERVIEW

       Since tack is designed to test terminfo's it is not possi­
       ble  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 dis­
       play.  When in doubt the question mark (?) is a good char­
       acter 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 infor­
       mation 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 proceed­


CREATING NEW ENTRIES

       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 ini­
       tialization and default the standard entries.

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

       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 charac­
       ters 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  avail­
       able 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  stan­
       dard 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 ter­
       minal.  It goes through attribute numbers 0  to  79,  dis­
       playing  each  in  turn and using that SGR number to write
       the text.  This shows you which of the SGR modes are actu­
       ally  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 ter­
       minal.

       This will bring up a secondary menu  that  allows  you  to
       select more specific tests.

       The  general  philosophy of the program is, for each capa­
       bility, to send an appropriate test pattern to the  termi­
       nal  then  send  a  description  of  what  the user should
       expect.  Occasionally (as when checking function-key capa­
       bilities)  the  program will ask you to enter input for it
       to check.

       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 sub­
       menu 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.


CORRECTING PAD TIMINGS

   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 termi­
       nal  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 trans­
       mission 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-look­
       ing displays.  This kind of glitch is called an overrun.

       One common way to avoid overruns is  with  XON/XOFF  hand­
       shaking.   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.  How­
       ever,  there  is  a  small amount of time between the stop
       request and the actual stop.  During this window, the ter­
       minal  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  termi­
       nal  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 prob­
       lem much worse.

       (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  dif­
       ferent  type of handshaking than the XON/XOFF that is sup­
       ported 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 attributes'.

          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 termi­
       nating  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 termi­
       nating character until the length of the expected acknowl­

   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 effec­
       tive  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 multi­
       plier, which is used if the pad prefix includes  `*'.   In
       curses  use,  it is often the first parameter of the capa­
       bility (if there is one).  For a capability like (dch)  or
       (il)  this  will  be  the number of character positions or
       lines affected, respectively.

       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).


NOTE

       The tests done at the beginning of the program are assumed
       to be correct later in the code.  In particular, tack dis­
       plays  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.
       terminfo(5), ncurses(3NCURSES), tic(1m), infocmp(1m).  You
       should also have the documentation supplied by the  termi­
       nal manufacturer.


BUGS

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


AUTHOR

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

                                                         tack(1M)
  

Looking for a "printer friendly" version?


Login
Nickname

Password

Security Code
Security Code
Type Security Code


Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Help if you can!


Amazon Wish List

Did You Know?
You can help in many different ways.


Friends



Tell a Friend About Us

Bookmark and Share



Web site powered by PHP-Nuke

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved.
The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look here

PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.10 Seconds