tack(1)

📦
version 1.11+20251210 · 4 versions
, in ubuntu resolute, ubuntu stonking

✨ NAME ✨

okay so bestie, let me introduce you to tack — the terminfo action checker 💅 it's a User command, and it is literally about to become your new fave when you're out here wrestling with terminal entries. tack(1), periodt. 🎀

🌸 SYNOPSIS 🌸

tack [-diltV] [term]

💖 DESCRIPTION 💖

so like, tack has three whole purposes, and honestly? iconic multitasking 💅

  1. it helps you build a brand new terminfo entry describing an unknown terminal 🧚
  2. it tests whether an existing entry is even correct (vibe check for terminfo, fr fr) 🔥
  3. it helps you develop the correct pad timings so that screen updates never fall behind the incoming data stream 😭 no lag, no drama

tack shows you a whole series of screen-painting and interactive tests, and it sets them up on purpose so that any mismatch between the terminfo entry and actual reality is visually obvious — like, you cannot miss it. it also hands you tools that help you understand how your terminal operates 🦋

🎀 OPTIONS 🎀

  • -d — starts tack with the debug-file debug.log opened 📝
  • -i — normally tack sends the reset and init strings to the terminal when the program starts up. this option inhibits the terminal initialization 🙈
  • -l — starts tack with the log-file tack.log opened. this is also a menu item, iykyk 🍓
  • -t — tells 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
    • (ht) to \t
  • -V — displays the version information and exits 👋
  • term — the terminfo terminal name to be tested. if it's not present, then the $TERM environment variable gets used instead 💜

🦋 OVERVIEW 🦋

so here's the thing — since tack is designed to test terminfo entries, it literally cannot rely on the terminfo database being correct 💀 because of that, the menuing system used with tack is very primitive. when a menu prints, it will scroll the entire screen. yes, the whole thing. 😭

to compensate for this verbose menu situation, tack lets you do menu selection type ahead ✨ if you already know what action you want tack to perform, you can just enter that value immediately and skip the menu display entirely. main character energy. when in doubt, the question mark (?) is a good character to type. a carriage return will execute the default action, and those default actions are designed to run all the standard tests 👑

when tack first comes up it displays some basic information about the terminal. take some time to verify this info, bestie, seriously — first up are the cursor movement and clearing capabilities. if any of those are wrong, many of the subsequent tests will fail 😭

  • (home) and (clear) are also critical to the success of subsequent tests.
  • the values of (cr) (ind) (cub1) and (ht) may affect the tests if they are defined incorrectly. if they are undefined, tack will set them to reasonable defaults 🫶

after these basic capabilities, tack shows optional features which may provide information:

  • the enquire (ENQ) and acknowledge (ACK) strings are taken from the user strings (u9) and (u8) 🔍
  • if the screen has at least 30 lines, there's room to display ncurses extensions for secondary device attributes (DA2) and terminal version ⭐

the most important item is the screen size. if the screen size is wrong, there is literally no point in proceeding. periodt. 🛑

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 that tack is designed to rely on as little of the terminfo entry as possible 💅

🌈 CREATING NEW ENTRIES 🌈

tack has a bunch of tools designed to help you gather information about the terminal. although these functions are not dependent on terminal type, you may wish to execute tack with options -it — this turns off initialization and defaults the standard entries ✨

you can reach these tools 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 — they're sent as control characters, so you can test an escape sequence and see what it actually does 👀 you may also elect to enable hex output on echo tool, which 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 helps 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 119, 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 an 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, and 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, and standard character sets are located in the alphabetic range 🎀

👑 VERIFYING AN EXISTING ENTRY 👑

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). it brings up a secondary menu that lets you select more specific tests 💅

the general philosophy of the program is, for each capability, to send an appropriate test pattern to the terminal and 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 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 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 too, 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 database 🎀

💖 CORRECTING PAD TIMINGS 💖

🌈 Theory of Overruns and Padding

okay so bestie, here's the tea ☕ — some terminals need a LOT of time to do big screen updates. like, more than one transmitted-character interval of time. we're talking screen clears, line insertions, line deletions, and scrolls (yes, including scrolls triggered by line feeds or by writing to the lowest, right-hand-most cell of the screen). those are the big dramatic moves and the terminal needs a sec to recover 😮‍💨

and if your computer just keeps yapping at the terminal while one of those slow operations is happening? screen go garbled. 💀 because the length of a character transmission time varies inversely with transmission speed in cps, entries that work fine at lower speeds can straight-up break at higher speeds. it's giving betrayal.

same kind of chaos happens if the host machine is just sending characters at a sustained rate faster than the terminal can buffer and process them. either way, when the terminal can't process them and can't tell the host to stop soon enough, it just drops them. and the dropped characters could be text, escape sequences, or the escape character itself — which makes for some truly unhinged-looking displays 🙈 this whole glitch situation is called an overrun.

so in terminfo entries, you can attach a pad time to each string capability. it's a number of milliseconds to delay after sending that string. gives the terminal a lil moment to catch up and avoid the overrun. self care ✨

now — if you're running a software terminal emulator, or you're on an X pseudo-tty, or your terminal is on an RS-232C line that correctly handles RTS/CTS hardware flow control, then pads are not strictly necessary. BUT (and this is the plot twist) 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 bestie… even this handshake may have problems at high baud rates. and here's why — it's literally just how XON/XOFF works. the terminal tells the host to stop with an XOFF. when the host gets that character, it stops sending. however, there's a small window of time between the stop request and the actual stop. during that window, the terminal has to keep accepting characters even though it already told the host to stop. if it sends the stop request too late, its internal buffer overflows. if it sends the stop character too early, then the terminal isn't 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 😭 and connecting the terminal over a network? makes the problem 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

so to get accurate timings, tack needs to know when the terminal has finished processing all the characters that were sent. that requires a different type of handshaking than the XON/XOFF that most terminals support. tack needs to send a request to the terminal and then 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

and 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 Tektronix 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

ngl, the pad timings in distributed terminfo entries are often incorrect. and one major motivation for this program is to make it relatively easy to tune these timings. you're welcome bestie 😌

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. and 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, 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 gotta make that decision yourself by rerunning the test with a different multiplier. here's the vibe check:

  • if the padding changes in proportion to the multiplier, then 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. also, system load will affect the results — a heavily loaded system will not stress the terminal as much, possibly leading to pad timings that are too short. 😭

📁 FILES 📁

  • 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. 🎀

📝 NOTES 📝

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. 💀 no pressure or anything.

💀 BUGS 💀

if the screen size is incorrect, many of the tests will fail. that's it, that's the bug. iconic honesty honestly 🫶

👑 AUTHORS 👑

  • Concept, design, and original implementation by Daniel Weaver <dan.weaver@znyx.com>.
  • Portions of the code and documentation are by Eric S. Raymond <esr@snark.thyrsus.com>.
  • Refactored by Thomas E. Dickey to eliminate dependency on ncurses internal functions, and to allow tack to work with other implementations of curses and terminfo than ncurses.

🌸 SEE ALSO 🌸

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

and that's the whole page bestie!! 🦋 this little legend calls itself the terminfo action checker, and the version you're looking at is dated 2025-04-27, filed under tack(1). now go forth and pad those timings correctly, you absolute main character 🎀✨💖

📦 where this page comes from