Device Capability Database¶
A selected collection of machine-readable device descriptions lets software use shared capability names to adapt commands and output to different device types.
Core Idea¶
A device capability database lets one program work with different kinds of devices by reading selected descriptions instead of building every device detail into the program. A supplied terminal type or configured printer queue chooses a description. The program asks for named capabilities, reads their stored values, and uses those values to adapt its output.
Terminfo stores terminal descriptions and control capabilities that software such as tput can request.[ref-ce0eb2a472b3][ref-8a4daf6ab7dd] In legacy CUPS printing, a selected PostScript Printer Description (PPD) file describes printer options and commands that the print system can use.[ref-b596e81a73a4][ref-779f134223b4][^ref-103af2622b85] The shared idea is selected description → named lookup → device-specific action. The database does not detect the physical device; another setting supplies the selector.[ref-8a4daf6ab7dd][ref-103af2622b85]
This is a kind of Lookup Table. Its entries associate supplied device and capability keys with prepared values. It adds a device-control vocabulary and software that acts on the retrieved values. A general table of numbers can be a Lookup Table without being a device capability database.
What It Is Not¶
A device capability database is not a device driver by itself. The description holds facts and commands; a client, scheduler, or filter must interpret them. CUPS documents advanced printer features that need filters or other supporting files beyond a PPD.[^ref-779f134223b4]
It is not an automatic hardware detector or a promise that any new device works by adding one file. A terminal type can be supplied through TERM or tput -T, and a CUPS queue can select a PPD.[ref-8a4daf6ab7dd][ref-103af2622b85] The existing client must understand the capability name and value. PPD printing is a documented legacy example: OpenPrinting says CUPS printer-driver support was deprecated beginning with CUPS 2.3.[^ref-46a8b89fee0a]
It is not required to be one physical table. Terminfo uses a database of terminal descriptions; a set of selected PPD files can play the same collection role for printers.[ref-ce0eb2a472b3][ref-b596e81a73a4]
Scope of Application¶
The pattern applies when software must issue different operations to several device types through a common interface. A terminfo client selects a terminal description and can retrieve Boolean, numeric, or string capabilities, including control strings.[ref-ce0eb2a472b3][ref-8a4daf6ab7dd] A legacy CUPS print path selects a printer description and uses PPD options and commands, sometimes together with filters.[ref-b596e81a73a4][ref-779f134223b4][^ref-103af2622b85]
A stored description must be selected and consumed. A program with only hard-coded branches may adapt to devices, but it lacks this database-mediated form. A passive capability file that no client reads does not adapt output.
Clarity¶
To recognize the pattern, ask: Who supplies the device type? Where are its facts stored? Which names can the client request? What action uses the answer? These questions separate the stored description from device discovery and executable driver logic.
Also distinguish an absent known capability from an unsupported new feature. ncurses tiget* functions document return values for missing or canceled capabilities, and the legacy CUPS ppdFindOption lookup can return NULL when an option is not found.[ref-0b009bc94097][ref-20a4ff61eae0] Those are lookup outcomes. A capability outside the client's vocabulary may require changed software, not merely a new record.
Manages Complexity¶
Named capability records let one client reuse its logic across device types. Different terminal control strings can live under common terminfo names; printer-specific options can live in PPDs.[ref-ce0eb2a472b3][ref-b596e81a73a4] A new description can extend a client when its existing names and interpretation code already cover the needed behavior.
That condition matters. A wrong selector applies the wrong facts. An inaccurate record can cause wrong output. New hardware may require a new name, a new interpretation rule, or an extra filter. OpenPrinting identifies PPD limits in representing modern printer capabilities and dynamic state.[^ref-46a8b89fee0a]
Abstract Reasoning¶
Trace supplied type → selected description → named capability → retrieved value → adapted operation. If the client never consults the record, remove the database from the explanation. If changing only the record cannot express or execute a new operation, the extension requires software work as well.
The same reasoning separates two errors: choosing the wrong description and storing a wrong value in the right description. Both can produce incorrect commands, but they require different repairs.
Knowledge Transfer¶
Terminfo and legacy PPD printing use unlike names, formats, and operations. Their common structure is a selected external description, a vocabulary shared by a client, and output adapted from retrieved values.[ref-ce0eb2a472b3][ref-b596e81a73a4][^ref-779f134223b4] Transfer that role map, not terminal escape codes or printer option names.
The broader Lookup Table genus supplies prepared associations and a lookup rule; this child adds device types, capability meanings, and an operative client. Indirection is a related Prime because the named lookup mediates device-dependent behavior. Neither every lookup table nor every device driver has this identity.
Examples¶
Terminal control with terminfo. Terminfo holds named capabilities for terminal types. A script using tput selects a terminal through TERM or -T and asks for a capability such as a control string.[ref-ce0eb2a472b3][ref-8a4daf6ab7dd] Mapped back: supplied terminal type = selector; terminfo record = stored description; capability name = lookup key; tput = client; resulting control sequence = adapted operation. The record does not identify attached hardware.
Legacy printer description with CUPS. A CUPS queue can select a printer model or PPD file. The PPD describes options and commands; the print system uses it with its scheduler and, when needed, filters to prepare output for that printer.[ref-103af2622b85][ref-b596e81a73a4][^ref-779f134223b4] Mapped back: configured queue = selector; PPD = stored description; option keywords = lookup names; CUPS print path = client; printer-specific output = adapted operation. A PPD alone may not implement advanced features, and this is a legacy driver architecture.[ref-779f134223b4][ref-46a8b89fee0a]
Relationships to Other Abstractions¶
Current abstraction Device Capability Database Domain-specific
Parents (1) — more general patterns this builds on
-
Device Capability Database is a kind of Lookup Table Domain-specific
A Device Capability Database is a Lookup Table whose stored keyed associations describe device capabilities and commands that a client uses to adapt output.
Hierarchy path (1) — routes to 1 parentless root
- Device Capability Database → Lookup Table
Neighborhood in Abstraction Space¶
Device Capability Database sits in a sparse region of the domain-specific corpus (100th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.
Family — Unclustered & Miscellaneous (2721 abstractions)
Nearest neighbors
- Computer Peripheral — 0.73
- Abstract Factory Pattern — 0.72
- Object-Oriented Operating System — 0.72
- Unix Domain Socket — 0.72
- Crossover effects — 0.72
Computed from structural-signature embeddings · 2026-10-17
References¶
[^ref-ce0eb2a472b3]: Zeyd M. Ben-Halim, Eric S. Raymond, and Thomas E. Dickey, “terminfo(5) terminal capability database,” ncurses 6.6 manual, patch 20260919, https://invisible-island.net/ncurses/man/terminfo.5.html (original implementer reference, full HTML inspected; DESCRIPTION, Entry and Capabilities Syntax, Standard Capabilities, and Preparing Descriptions).
[^ref-8a4daf6ab7dd]: ncurses project, “tput(1) initialize a terminal, exercise its capabilities, or query terminfo database,” ncurses 6.6 manual, https://www.invisible-island.net/ncurses/man/tput.1.html (original implementer reference, full HTML inspected; DESCRIPTION, -T option, TERM environment, and EXAMPLES).
[^ref-b596e81a73a4]: OpenPrinting/CUPS, “CUPS PPD Extensions,” https://www.cups.org/doc/spec-ppd.html (official format specification, full HTML inspected; introduction and option-command examples).
[^ref-779f134223b4]: OpenPrinting/CUPS, “Developing PostScript Printer Drivers,” https://www.cups.org/doc/postscript-driver.html (official implementer guide, full HTML inspected; Printer Driver Basics and Creating New PPD Files).
[^ref-103af2622b85]: OpenPrinting/CUPS, “lpadmin(8),” https://www.cups.org/doc/man-lpadmin.html (official command reference, full HTML inspected; -m model and -P ppd-file printer queue selection options).
[^ref-46a8b89fee0a]: OpenPrinting, “Printer Applications and Printer Drivers,” https://openprinting.github.io/cups/drivers.html (original project documentation, full HTML inspected; deprecation statement, PPD expressivity limits, and replacement architecture discussion).
[^ref-0b009bc94097]: ncurses project, “curs_terminfo(3x) curses interfaces to terminfo database,” ncurses 6.6 manual, https://invisible-island.net/ncurses/man/curs_terminfo.3x.html (original implementer reference, full HTML inspected; Terminal Capability Functions gives type-error versus absent/canceled return values for tigetflag, tigetnum, and tigetstr).
[^ref-20a4ff61eae0]: OpenPrinting/CUPS, “PPD API (Deprecated),” https://www.cups.org/doc/api-ppd.html (official legacy API reference, full HTML inspected; ppdFindOption returns a pointer or NULL when an option is not found).