Hubbry Logo
Text-based user interfaceText-based user interfaceMain
Open search
Text-based user interface
Community hub
Text-based user interface
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Text-based user interface
Text-based user interface
Text-based user interface
View on Wikipedia
from Wikipedia
Some file managers implement a TUI (here: Midnight Commander)
Vim is a very widely used TUI text editor.

In computing, text-based user interfaces (TUI) (alternately terminal user interfaces, to reflect a dependence upon the properties of computer terminals and not just text), is a retronym describing a type of user interface (UI) common as an early form of human–computer interaction, before the advent of bitmapped displays and modern conventional graphical user interfaces (GUIs). Like modern GUIs, they can use the entire screen area and may accept mouse and other inputs. They may also use color and often structure the display using box-drawing characters such as ┌ and ╣. The modern context of use is usually a terminal emulator.

Types of text terminals

[edit]

In the early years of computing, text terminals were usually keyboard/printer devices. Currently, however, keyboard/display devices dominate.

A text screen (and communications with it) can belong to one of three types (here ordered in order of decreasing accessibility):

  1. A local text mode display, controlled by a video adapter or the central processor itself. This is a normal condition for a locally running application on various types of personal computers and mobile devices. If not deterred by the operating system, a smart program may exploit the full power of a hardware text mode.
  2. A text mode emulator. Examples are TN3270, xterm for X Window System and win32 console (in a window mode) for Microsoft Windows. This usually supports programs that expect a real text mode display, but may run considerably slower. Certain functions of an advanced text mode, such as an own font uploading, almost certainly become unavailable.
  3. A remote text terminal. The communication capabilities usually become reduced to a serial line or its emulation, possibly with few ioctl()s as an out-of-band channel in such cases as Telnet and Secure Shell. This is the worst case, because software restrictions hinder the use of capabilities of a remote display device.

From text application's point of view, the display type is determined by the API, e.g., curses, TPUT.

Under Linux and other Unix-like systems, a program easily accommodates to any of the three cases because the same interface (namely, standard streams) controls the display and keyboard. See below for comparison to Windows.

Many TUI programming libraries are available to help developers build TUI applications.

On ANSI-compatible terminals

[edit]

American National Standards Institute (ANSI) standard ANSI X3.64 defines a standard set of escape sequences that can be used to drive terminals to create TUIs (see ANSI escape code). Escape sequences may be supported for all three cases mentioned in the above section, allowing arbitrary cursor movements and color changes. However, not all terminals follow this standard, and many non-compatible but functionally equivalent sequences exist.

Under DOS and Microsoft Windows

[edit]
The FreeDOS Edit user interface

On IBM Personal Computers and compatibles, the Basic Input Output System (BIOS) and DOS system calls provide a way to write text on the screen, and the ANSI.SYS driver could process standard ANSI escape sequences. However, programmers soon learned that writing data directly to the screen buffer was far faster and simpler to program, and less error-prone; see VGA-compatible text mode for details. This change in programming methods resulted in many DOS TUI programs. The Windows console environment is notorious for its emulation of certain EGA/VGA text mode features, particularly random access to the text buffer, even if the application runs in a window. On the other hand, programs running under Windows (both native and DOS applications) have much less control of the display and keyboard than Linux and DOS programs can have, because of aforementioned Windows console layer.

Mouse cursor in Impulse Tracker. A more precise cursor (per-pixel resolution) was achieved by regenerating the glyphs of characters used where the cursor was visible, at each mouse movement in real-time.[citation needed]

Most often those programs used a blue background for the main screen, with white or yellow characters, although commonly they had also user color customization. They often used box-drawing characters in IBM's code page 437. Later, the interface became deeply influenced by graphical user interfaces (GUI), adding pull-down menus, overlapping windows, dialog boxes and GUI widgets operated by mnemonics or keyboard shortcuts. Soon mouse input was added – either at text resolution as a simple colored box or at graphical resolution thanks to the ability of the Enhanced Graphics Adapter (EGA) and Video Graphics Array (VGA) display adapters to redefine the text character shapes by software – providing additional functions.

Some notable programs of this kind were Microsoft Word, DOS Shell, WordPerfect, Norton Commander, Turbo Vision based Borland Turbo Pascal and Turbo C (the latter included the conio library), Lotus 1-2-3 and many others. Some of these interfaces survived even during the Microsoft Windows 3.1x period in the early 1990s. For example, the Microsoft C 6.0 compiler, used to write true GUI programs under 16-bit Windows, still has its own TUI.

Since its start, Microsoft Windows includes a console to display DOS software. Later versions added the Windows console as a native interface for command-line interface and TUI programs. The console usually opens in window mode, but it can be switched to full, true text mode screen and vice versa by pressing the Alt and Enter keys together. Full-screen mode is not available in Windows Vista and later, but may be used with some workarounds.[1]

Windows Terminal is a multi-tabbed terminal emulator that Microsoft has developed for Windows 10 and later[2] as a replacement for Windows Console.

The Windows Subsystem for Linux which was added to Windows by Microsoft in 2019, supports running Linux text-based apps on Windows, within Windows console, Windows Terminal, and other Windows-based terminals.

Under Unix-like systems

[edit]
Snapshot of 'XFdrake', a TUI used in Mandriva Linux to configure the graphical system
btop - task manager utility for Linux and other unix-like OS

In Unix-like operating systems, TUIs are often constructed using the terminal control library curses, or ncurses (a mostly compatible library), or the alternative S-Lang library. The advent of the curses library with Berkeley Unix created a portable and stable API for which to write TUIs. The ability to talk to various text terminal types using the same interfaces led to more widespread use of "visual" Unix programs, which occupied the entire terminal screen instead of using a simple line interface. This can be seen in text editors such as vi, mail clients such as pine or mutt, system management tools such as SMIT, SAM, FreeBSD's Sysinstall and web browsers such as lynx. Some applications, such as w3m, and older versions of pine and vi use the less-able termcap library, performing many of the functions associated with curses within the application. Custom TUI applications based on widgets can be easily developed using the dialog program (based on ncurses), or the Whiptail program (based on S-Lang).

In addition, the rise in popularity of Linux brought many former DOS users to a Unix-like platform, which has fostered a DOS influence in many TUIs. The program minicom, for example, is modeled after the popular DOS program Telix. Some other TUI programs, such as the Twin desktop, were ported over.

Most Unix-like operating systems (Linux, FreeBSD, etc.) support virtual consoles, typically accessed through a Ctrl-Alt-F key combination. For example, under Linux up to 64 consoles may be accessed (12 via function keys), each displaying in full-screen text mode.

The free software program GNU Screen provides for managing multiple sessions inside a single TUI, and so can be thought of as being like a window manager for text-mode and command-line interfaces. Tmux can also do this.

The proprietary macOS text editor BBEdit includes a shell worksheet function that works as a full-screen shell window. The free Emacs text editor can run a shell inside of one of its buffers to provide similar functionality. There are several shell implementations in Emacs, but only ansi-term is suitable for running TUI programs. The other common shell modes, shell and eshell only emulate command lines and TUI programs will complain "Terminal is not fully functional" or display a garbled interface. The free Vim and Neovim text editors have terminal windows (simulating xterm). The feature is intended for running jobs, parallel builds, or tests, but can also be used (with window splits and tab pages) as a lightweight terminal multiplexer.

OpenVMS

[edit]

VAX/VMS (later known as OpenVMS) had a similar facility to curses known as the Screen Management facility or SMG. This could be invoked from the command line or called from programs using the SMG$ library.[3]

Oberon

[edit]
Screenshot of the desktop of an Oberon System showing an image and several text viewers

Another kind of TUI is the primary interface of the Oberon operating system, first released in 1988 and still maintained. Unlike most other text-based user interfaces, Oberon does not use a text-mode console or terminal, but requires a large bit-mapped display, on which text is the primary target for mouse clicks. Analogous to a link in hypertext, a command has the format Module.Procedure parameters ~ and is activated with a mouse middle-click. Text displayed anywhere on the screen can be edited, and if formatted with the required command syntax, can be middle-clicked and executed. Any text file containing suitably-formatted commands can be used as a so-called tool text, thus serving as a user-configurable menu. Even the output of a previous command can be edited and used as a new command. This approach is radically different from both conventional dialogue-oriented console menus or command-line interfaces but bears some similarities to the worksheet interface of the Macintosh Programmer's Workshop.

Since it does not use graphical widgets, only plain text, but offers comparable functionality to a GUI with a tiling window manager, it is referred to as a Text User Interface or TUI. For a short introduction, see the 2nd paragraph on page four of the first published Report on the Oberon System.[4]

Oberon's UI influenced the design of the Acme text editor and email client for the Plan 9 from Bell Labs operating system.

In embedded systems

[edit]
Embedded system displaying menu on an LCD screen

Modern embedded systems are capable of displaying TUI on a monitor like personal computers. This functionality is usually implemented using specialized integrated circuits, modules, or using FPGA.

Video circuits or modules are usually controlled using VT100-compatible command set over UART,[citation needed] FPGA designs usually allow direct video memory access.[citation needed]

Other uses

[edit]
  • The full screen editor of the Commodore 64 8-bit computers was advanced in its market segment for its time. Users could move the cursor over the entire screen area, entering and editing BASIC program lines, as well as direct mode commands. All Commodore 8-bit computers used the PETSCII character set, which included character glyphs suitable for making a TUI.
  • Apple's Macintosh Programmer's Workshop programming environment included Commando, a TUI shell. It was the inspiration for BBEdit's shell worksheet.
  • Later Apple II models included MouseText, a set of graphical glyphs used for making a TUI.
  • The Corvus Concept computer of 1982 used a function key-based text interface on a full-page pivoting display.

See also

[edit]

Examples of programming libraries

[edit]

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Text-based user interface

View on Grokipedia
from Grokipedia
A text-based user interface (TUI), also known as a textual user interface or terminal user interface, is a form of human-computer interaction in which digital information is displayed and user input is received exclusively through text characters arranged in a terminal or console environment, often simulating graphical elements like windows, menus, and dialogs using character-based rendering. Unlike simple command-line interfaces (CLIs), which process input line-by-line, TUIs leverage the full screen area for persistent, interactive displays that support cursor movement, , and multi-region layouts, enabling more structured navigation via keyboard (and sometimes ) controls. TUIs trace their origins to the earliest systems in the mid-20th century, beginning with teletypewriters (TTYs) that provided basic text input and output over serial connections, and evolving in the with video display terminals such as the Lear-Siegler ADM-3A and DEC VT100, which introduced cursor addressing and control sequences for dynamic screen updates. By the late , libraries like the original curses API—initially developed for the vi in (BSD) Unix—facilitated the creation of more sophisticated TUIs by abstracting terminal-specific behaviors through databases like and later . Modern implementations, such as the open-source library (initiated in the early 1990s as a portable clone of System V curses), extend these foundations with support for color, mouse events, characters, and extensions for panels, forms, and menus, ensuring compatibility across diverse terminal emulators like and . TUIs remain prevalent in server environments, embedded systems, and development tools due to their low resource demands—requiring minimal CPU, memory, and bandwidth compared to graphical user interfaces (GUIs)—making them ideal for remote access over networks and headless operation. They offer advantages in efficiency for expert users, such as rapid keyboard-driven workflows and easy scripting or , as demonstrated in studies where TUIs enabled faster task completion in scenarios like electronic dental records. However, TUIs can pose disadvantages for novices, including a steeper due to reliance on memorized commands and modes (e.g., vi's normal and insert modes), limited visual intuitiveness, and challenges with for screen readers or complex scripts like . Notable examples include the vim editor and its extensible fork neovim (written in C and Lua), which build on vi's TUI foundations for modal text manipulation with modern features; package managers like ; and full applications such as for system monitoring, highlighting TUIs' enduring role in ecosystems.

Fundamentals

Definition and Characteristics

A text-based (TUI), also referred to as a text , is a type of that relies exclusively on text characters for both input and output, using text characters to present information in a fixed grid, such as on a terminal or console display, often simulating graphical elements like windows and menus without bitmapped or icons. Distinct from command-line interfaces (CLIs), which handle input and output line-by-line, TUIs employ the full terminal screen for interactive, multi-region displays supporting cursor movement and structured navigation. This design enables direct communication between the user and the system through alphanumeric input and textual feedback, often within a character-based environment that supports only symbols, text, and limited formatting options available in text modes. Key characteristics of TUIs include their reliance on keyboard-driven input, where users enter commands or selections sequentially, and output that is typically or restricted to a basic color palette defined by the display hardware or software. Navigation occurs via command-line prompts, where users recall and type specific instructions, or through menu-based systems that present options as text lists, emphasizing user expertise in and function recall over visual recognition. TUIs primarily rely on keyboard-driven input for and commands, though advanced TUIs support interactions; they emphasize efficient, low-resource operations suitable for terminals. In contrast to graphical user interfaces (GUIs), which employ visual paradigms such as windows, pointers, and icons for intuitive point-and-click interactions, TUIs prioritize sequential text processing, where information is conveyed linearly and users interact through typed responses rather than spatial manipulation. This distinction highlights TUIs' suitability for environments demanding precise, scripted control, though they can pose challenges in navigation due to the absence of visual aids. Fundamental components of TUIs encompass cursor positioning mechanisms to relocate the active point on the screen, scrolling regions that handle text overflow by shifting content vertically or horizontally, and character encoding schemes like ASCII, which define a 7-bit standard for representing 128 characters including letters, digits, and control codes to ensure consistent text rendering across systems. These elements collectively enable the structured display and manipulation of text in a grid-based format, forming the backbone of TUI functionality.

Historical Context

The origins of text-based user interfaces trace back to electromechanical devices like teletypewriters, which emerged in the early but saw significant adoption in during the 1930s and 1940s as precursors to interactive text input and output. These machines, such as the Teletype Model 15 introduced in 1930, functioned as automated telegraphs capable of printing and transmitting text over distances, providing a foundation for remote and display in early computer systems. By the mid-1940s, they influenced the design of computing peripherals, exemplified by the (Electronic Numerical Integrator and Computer), completed in 1945, which primarily relied on punched cards read via an card reader for input and produced output through an card punch, with programming accomplished via switches and plugboards for operator control. The 1960s and 1970s marked a pivotal evolution toward more dynamic text-based interfaces, driven by the rise of systems that enabled multiple users to interact with a single computer via remote terminals. Pioneering efforts included John McCarthy's 1957 proposal for on the at MIT, leading to the development of the (CTSS) demonstrated in 1962 by Fernando Corbató, which allowed interactive text sessions over teletype connections. This period also saw the introduction of video display terminals (VDTs), with Digital Equipment Corporation's VT05 in 1970 representing a key milestone as the company's first raster-scan CRT terminal, supporting uppercase ASCII text in a 20-by-72 character display and basic cursor controls at 300 baud, effectively replacing mechanical teletypes with electronic screens for real-time text rendering. Concurrently, the , launched in 1969, influenced text-based networking through protocols like , which facilitated remote terminal access to host computers via text streams, and the Terminal Interface Processor (TIP) deployed in 1970 to connect up to 63 terminals directly to the network, promoting collaborative text interactions across distant sites. In the 1980s, standardization efforts solidified text-based interfaces for broader compatibility and functionality in personal and multi-user computing. The (ANSI) X3.64 standard, published in 1979 and widely adopted throughout the decade, defined control sequences using escape codes to manage cursor positioning, screen clearing, and text attributes on terminals, enabling consistent text manipulation across diverse hardware. This facilitated the integration of advanced text displays in systems like Unix workstations and early PCs, paving the way for widespread use in and academic environments. By the 1990s, the proliferation of graphical user interfaces (GUIs) began to diminish the prominence of text-based interfaces on consumer desktops, though they persisted in server and embedded applications. Microsoft's , released in 1990, accelerated this shift by providing an accessible GUI layer over , selling millions of copies and making point-and-click interactions the norm for most users, effectively sidelining command-line text operations. Similarly, the (X11), standardized in 1987 and dominant on Unix platforms by the early 1990s, supported networked GUIs while retaining text shells, but overall, GUIs like those in (1995) and emerging desktops drove a decline in pure text-based paradigms for general computing.

Types

Physical Terminals

Physical terminals represent dedicated hardware devices designed specifically for text-based interaction with computer systems, serving as the primary interface for input and output in early environments. These devices evolved from mechanical teletypes, which were essentially modified electric typewriters capable of text on rolls, to more advanced cathode-ray tube (CRT) displays that rendered characters on a phosphor-coated screen. Teletype-style printers, such as the introduced in the 1960s, operated by receiving electrical impulses to strike keys and produce printed output, functioning as both input and output peripherals connected to mainframes via serial lines. CRT-based terminals, emerging prominently in the 1970s, replaced with "glass teletypes" that displayed alphanumeric characters in a grid format, offering faster refresh rates and reduced noise compared to mechanical printers. Precursors to full included vector-based systems like the 4010, announced in 1971, which utilized a direct-view to persist text and simple line drawings without constant refreshing. Input and output mechanisms in physical terminals centered on integrated keyboards for character entry and protocols for data exchange with host computers. Keyboards typically featured typewriter-style layouts with additional function keys, directly wired to the terminal's logic board to encode keystrokes into ASCII or similar codes. Connections relied on serial interfaces, a standard established in 1960 for asynchronous data transmission between devices, supporting cable lengths up to 15 meters at lower speeds. rates, measuring bits per second, varied by terminal model but commonly included 110, 300, 1200, or 9600 bps to balance transmission speed with over twisted-pair wiring. The terminal acted as a "dumb" device, sending raw input to the host for processing and receiving formatted text streams for display, without local computation beyond basic rendering. A seminal example is the (DEC) VT100 series, introduced in August 1978, which standardized many terminal features with its 80-column by 24-row character grid displayed on a 14-inch CRT monochrome screen. The VT100 supported text attributes like bold and underline through overstriking techniques, where characters were reprinted in the same position to simulate emphasis, and included a detachable keyboard with 58 keys for efficient . Operating at baud rates up to 19,200 bps via , it connected to minicomputers like the PDP-11, enabling remote access for programming and data manipulation. Despite their reliability, physical terminals had inherent limitations rooted in hardware constraints, including fixed resolutions such as the standard 80 columns that restricted content width without or reconfiguration. They lacked native support for or color, confining output to text and simple attributes, as rendering was handled entirely by the host system rather than onboard processors. This dependency on remote processing introduced latency in interactive sessions, particularly at lower rates, and made terminals bulky, power-intensive units weighing 20-80 pounds.

Emulated and Virtual Terminals

Emulated terminals are software applications that replicate the functionality of physical text-based terminals within graphical user interfaces (GUIs), allowing users to interact with command-line programs as if using hardware devices. Pioneered in the mid-1980s, xterm serves as the standard terminal emulator for the X Window System, emulating DEC VT102 and VT220 terminals along with Tektronix 4014 graphics capabilities to provide compatibility for legacy and modern text applications. Similarly, PuTTY, first released in 1999 by Simon Tatham, offers an xterm-style emulation primarily for SSH and Telnet connections on Windows and Unix-like systems, enabling secure remote access to text interfaces. These emulators abstract hardware limitations by running as processes within window managers, supporting resizeable windows and integration with desktop environments while preserving essential terminal behaviors like cursor control and screen updates. Virtual terminals extend this concept through kernel-level multiplexing, providing multiple independent console sessions on a single physical display and keyboard without requiring a GUI. In , the kernel supports up to 63 virtual consoles, each functioning as a separate text environment that can be switched using key combinations such as Ctrl+Alt+F1 through F6, with the graphical desktop typically occupying one (e.g., F7). This multiplexing allows seamless transitions between sessions, such as logging into different user accounts or booting into recovery modes, and relies on the kernel's console drivers to handle . Unlike emulated terminals tied to GUIs, virtual terminals operate directly on the , offering a alternative for system administration and embedded use cases. Key features of emulated and virtual terminals enhance usability in contemporary systems. Windowing support in emulators like and permits multiple instances within a desktop, each configurable for size, position, and transparency, facilitating multitasking. Copy-paste integration bridges text selection with the host clipboard, often via middle-click or Ctrl+Shift+C/V shortcuts, streamlining data transfer between terminal and GUI applications. Unicode handling ensures support for international characters, with using tools like luit for UTF-8 encoding conversion and providing full Unicode for usernames, passwords, and display since version 0.82. Performance in these environments hinges on efficient buffer management to handle scrolling and output rendering without lag. Emulators maintain a scrollback buffer—typically thousands of lines—to retain off-screen history, allowing users to review previous commands and outputs via mouse wheel or keyboard navigation, with optimizations like circular buffers preventing excessive use. For visual enhancements, support for 256-color extensions, introduced in in 1999 by maintainer Thomas Dickey via patches extending ANSI escape sequences, enables richer text rendering with a palette including 16 standard colors, 216 RGB approximations, and 24 grayscale shades, improving readability in applications like code editors. These mechanisms ensure responsive operation even under high-output loads, such as log monitoring or compilation processes.

Standardization

ANSI and Escape Sequences

The ANSI X3.64 standard (1979), which adopted the ECMA-48 standard (1st ed. 1976) from the European Computer Manufacturers Association, establishes a protocol for encoded control functions in text terminals, enabling precise manipulation of cursor position, screen content, and display attributes through in-band signaling. ECMA-48, first published in 1976 with the 5th edition in 1991, provides the foundational control functions. This standard augments the ASCII code by defining sequences that begin with the Escape character (ESC, ASCII 27, hex 1B), often followed by a Control Sequence Introducer (CSI, represented as ESC [ or the single byte 0x9B in 8-bit environments), numeric parameters separated by semicolons, and a final non-printing character to invoke the function. For instance, the sequence format for setting foreground color follows the pattern ESC [ n m, where n specifies the color code within the SGR (Select Graphic Rendition) parameters. Among the most frequently used sequences are those for cursor control and screen editing. Cursor movement employs commands like ESC [ Pn A (Cursor Up by Pn lines, default 1), ESC [ Pn B (Cursor Down), ESC [ Pn C (Cursor Forward), and ESC [ Pn D (Cursor Backward), while absolute positioning uses ESC [ row ; col H to move the cursor to the specified row and column coordinates (origin at 1,1). Screen clearing is achieved with the Erase in Display (ED) sequence, such as ESC [ 2 J to wipe the entire screen from the cursor to the end, start, or both. Attribute modifications rely on the versatile SGR sequence ESC [ Ps m, where Ps values include 1 for bold (increased intensity), 5 for slow blink (rate under 150 cycles per minute), 22 to reset intensity to normal, and 25 to stop blinking. The core standard provides support for a basic 8-color palette in the SGR parameters, assigning foreground colors via ESC [ 30 m (black) through ESC [ 37 m (white) and backgrounds via ESC [ 40 m to ESC [ 47 m, with Ps=0 resetting to default. This palette was extended in terminal implementations to 16 colors by incorporating high-intensity variants (e.g., ESC [ 90 m to ESC [ 97 m for bright foregrounds), and further to 256 colors using the parameterized form ESC [ 38 ; 5 ; n m for foreground (or 48 for background), where n ranges from 0 to 255 to index an extended palette blending the basic colors with grayscale and RGB approximations. These color extensions, while not defined in the original ECMA-48 specification, became de facto standards through adoption in emulators like , enabling richer visual feedback in text UIs without deviating from the CSI format. ANSI X3.64 was withdrawn in 1997, with ISO/IEC 6429 serving as the current . Non-ANSI terminals pose compatibility challenges, as they may lack support for CSI sequences, resulting in uninterpreted escape codes appearing as literal characters or causing display artifacts. The terminal, released by in 1983, addressed some limitations by implementing the full ANSI X3.64 set alongside proprietary extensions, such as DEC private modes for features like double-width characters, status line reporting, and enhanced keyboard mappings, thereby broadening applicability for international and advanced text-based interactions.

Other Protocols and Standards

The protocol, introduced by in 1975, provided basic cursor control and screen management capabilities for early video terminals through a set of proprietary escape sequences, predating standardized approaches and enabling simple text positioning without full ANSI compatibility. These sequences allowed for operations like moving the cursor to specific coordinates and clearing portions of the screen, serving as a foundational model for subsequent terminal controls. The protocol, specified in RFC 854 published in May 1983, enables remote terminal access over networks by establishing a bi-directional, byte-oriented communication channel that negotiates terminal characteristics through option commands like DO, DON'T, WILL, and WON'T, allowing dynamic agreement on features such as echoing and line mode. This negotiation ensures compatibility between diverse terminal types and hosts, treating the connection as a Network Virtual Terminal (NVT) with seven-bit US-ASCII mapping. ISO/IEC 6429, first published in 1988 and revised in 1992, serves as the international standard for control functions in coded character sets, specifying encoded representations for operations like cursor movement, screen clearing, and device status reporting in both 7-bit and 8-bit environments, functioning as a global equivalent to ANSI X3.64. It supports interoperability across systems by defining a core set of functions applicable to text-imaging devices, including extensions for parameterized controls.

Implementations

Unix-like Systems

In Unix-like systems, text-based user interfaces are fundamentally supported through the kernel's terminal (TTY) subsystem, which manages communication between processes and terminal devices, including virtual consoles and pseudo-terminals (PTYs). The TTY layer handles serial devices and virtual ones like PTYs, providing a unified interface for operations. PTYs consist of a master and slave pair, enabling processes to interact as if connected to a real terminal; the master end is controlled by a program like a shell, while the slave mimics a physical terminal for the process. This setup allows multiple independent sessions on a single physical terminal, crucial for multi-user environments. The termios API, part of the standard, governs terminal attributes and line discipline in user space, allowing programs to configure input processing, such as echoing characters or handling special keys like . In the , the N_TTY line discipline implements canonical and non-canonical modes for line editing and raw input, respectively, ensuring efficient handling of text streams without buffering delays in interactive applications. This API is accessed via functions like tcgetattr() and tcsetattr(), which retrieve and set the termios structure defining baud rates, parity, and control characters. Command-line shells like Bash, first released in 1989, and Zsh, released in 1990, provide interactive text-based interfaces built atop the TTY subsystem. Bash, the Bourne-Again SHell, integrates the GNU Readline library for line editing, navigation, and features like tab completion for commands and filenames in . Readline supports Emacs-style key bindings and incremental search, enhancing usability in terminal environments. Zsh extends similar capabilities natively, offering advanced tab completion with context-aware suggestions and programmable widgets for custom editing behaviors. Both shells rely on the TERM environment variable to adapt their output to the terminal type, ensuring proper rendering of prompts and escapes. Terminal multiplexers extend TTY functionality by allowing multiple sessions within a single terminal window, facilitating session persistence and splitting. GNU Screen, originating in 1987, creates virtual terminals via PTYs, enabling users to detach and reattach sessions across network interruptions, with support for logging and hardcopy output. Tmux, released in 2007 and written in C, is a terminal multiplexer for session management that improves on this with a client-server model using PTYs for each pane and window, offering features like synchronized input across panes and vi/emacs key modes for navigation. These tools are essential for remote administration and development workflows in Unix-like systems. Integration with graphical environments occurs through emulators like , developed for the (X11), which emulates a text terminal while bridging to desktop sessions. Xterm creates a PTY for shell processes and sets the TERM variable to "xterm" or variants, informing applications of supported capabilities like color and mouse reporting. This allows text UIs to run seamlessly under X11, with escape sequences for cursor control and screen updates.

DOS and Microsoft Windows

In the DOS era, the command interpreter served as the primary text-based user interface shell for , introduced with version 1.0 on August 12, 1981. This shell operated in a standard 80x25 character , providing a fixed grid for displaying monochrome or color text output on compatible displays like the PC's CGA or later VGA adapters. To enhance text UI capabilities, the ANSI.SYS was developed in the , enabling support for ANSI escape sequences that allowed cursor movement, color changes, and screen clearing within the DOS environment when loaded via . With the advent of Windows NT in 1993, the operating system introduced a dedicated console subsystem to handle text-based interfaces, maintaining with DOS applications through a while providing native Win32 console APIs. This subsystem evolved with the introduction of ConHost.exe in (2009), which acts as the host process for console windows, separating console rendering from the (csrss.exe) for improved security and stability. The console supports characters via wide-character APIs like WriteConsoleW, allowing international text display, and includes functions such as SetConsoleTextAttribute for programmatic control of foreground and background colors in the output buffer. Command shells in Windows further diversified text UI interactions, with cmd.exe debuting in Windows NT 3.1 (1993) as a more robust replacement for COMMAND.COM, supporting batch scripting, environment variables, and redirection while emulating DOS behaviors. In contrast, Windows PowerShell, released on November 14, 2006, introduced an object-oriented approach to text output, piping .NET objects rather than plain text streams to enable richer scripting and automation beyond traditional line-based interfaces. A key limitation of the Windows console subsystem has been the absence of native pseudo-terminal (PTY) support, which hindered seamless integration with tools requiring virtual terminal emulation; this was addressed with the introduction of the Windows Pseudo Console (ConPTY) API in Windows 10 version 1809 (October 2018), facilitating PTY-like behavior and better interoperability with subsystems like (WSL) by 2019. Tools such as can emulate remote text UIs over SSH by leveraging these console APIs for local rendering.

Specialized Systems

In specialized operating systems, text-based user interfaces exhibit unique architectural adaptations tailored to their environments. OpenVMS, a multi-user enterprise operating system originally developed by Digital Equipment Corporation, employs the Digital Command Language (DCL) as its primary text-based command interpreter, announced in 1977 and first released in 1978 alongside VMS V1.0 for the VAX-11/780 computer. DCL provides an English-like syntax for issuing commands, managing processes, and interacting with system resources through a console terminal. Terminal input/output operations in OpenVMS are facilitated by the Record Management Services (RMS), a subsystem that enables record-oriented access to files and unit-record devices, including terminals and printers, with support for legacy DEC terminals such as the VT series through device drivers and control blocks like the File Access Block (FAB) and Record Access Block (RAB). RMS handles sequential record reads and writes, prompt buffering, and attributes like carriage control and timeouts, ensuring reliable interaction in multi-user time-sharing scenarios. The Oberon System represents another specialized approach, originating from a late 1980s project at ETH Zurich led by Niklaus Wirth and Jürg Gutknecht. Its text-based user interface revolves around a tiling window manager composed of "viewers"—rectangular frames displaying editable text that serves dual purposes as documents, source code, and interactive elements, manipulated via mouse selections and keyboard commands embedded directly in the text. This design embeds the UI logic within the Oberon programming language, allowing dynamic modifications without separate configuration files or external tools. In extensions like Active Oberon developed in the late 1990s (1996–1998), the interface incorporates gadget-based components, such as buttons and sliders, embedded as active objects within text windows to enhance interactivity while preserving the text-centric paradigm. A key architectural distinction lies in data handling and integration: OpenVMS relies on RMS for record-oriented files, where data is structured into fixed or variable-length records for efficient I/O across shared resources, contrasting with Oberon's modular approach, where the UI and system services are tightly coupled to the language's object-oriented constructs, enabling persistent, composable text elements without a separate file abstraction layer. OpenVMS has demonstrated longevity through ports to various architectures, including Itanium in 2003 and x86-64 with the first production release (V9.2) in July 2022, supporting modern virtualization environments like VMware and KVM as of 2025, while preserving text console support via serial ports and management interfaces for backward compatibility in enterprise deployments. Oberon variants, such as Bluebottle (later A2), continued development into the 2000s, maintaining the text-based interface paradigm.

Applications

Embedded Systems

In resource-constrained embedded environments, text-based user interfaces prioritize simplicity and efficiency, often interfacing with basic hardware displays limited to character output rather than graphical rendering. Common hardware includes LCD character displays driven by controllers like the HD44780, developed by in the , which supports alphanumeric text on modules such as 16x2 configurations with a 14-pin interface for control and data lines. These displays operate under tight constraints, including adjustable contrast via a bias pin and initialization sequences to set display modes, making them suitable for low-power applications where full pixel manipulation is unnecessary. Alternatively, serial UART interfaces enable text output over asynchronous communication using just two pins (TX and RX), facilitating console-like interactions in microcontrollers without dedicated display hardware. On the software side, implementations emphasize minimalism to fit within kilobytes of memory, such as , a modular suite originating in the that bundles a lightweight ash shell alongside stripped-down UNIX utilities into a single executable for embedded systems. This allows interactive command execution in environments with limited RAM and storage, where the ash shell provides POSIX-compliant scripting without the overhead of full-featured alternatives like bash. Custom firmware, typically written in C, further supports text I/O through functions like for formatted output to UART or LCD, enabling basic menus and status reporting directly in the application code. Representative examples illustrate these approaches in practice: the command-line interface (CLI), a text-based console for router configuration, relies on serial access for operational commands in embedded , supporting modes like user EXEC for monitoring and privileged EXEC for deeper control. In IoT devices, MicroPython's REPL (Read-Eval-Print Loop) offers an interactive text prompt over serial or USB, optimized for real-time code evaluation on resource-limited boards like the , with features such as auto-completion and interrupt handling to aid development without heavy tooling. To address memory limitations, optimizations in text rendering avoid complex terminal emulation, instead employing lightweight techniques like character cell grids overlaid on primitive graphics for UI elements such as menus and dialogs, as demonstrated in toolkits designed for low-tier systems with minimal computing resources. These methods ensure responsive interfaces on devices with under 1 MB of RAM, focusing on object-oriented abstractions that reduce code size while supporting overlapping windows and user interactions without demanding full ANSI compliance.

Modern and Niche Uses

In the , web-based text user interfaces emerged as a key enabler for and remote development, allowing terminals to run seamlessly within web browsers without native installations. xterm.js, a TypeScript-based front-end component released around 2017, provides fully-featured for web applications, supporting features like true-color rendering and input handling to deliver interactive shell experiences. It powers in-browser IDEs such as SourceLair, where users access remote shells for coding and debugging directly through the web. Complementing this, the Eclipse Theia platform, initiated in 2017 as an open-source IDE framework, integrates a built-in terminal emulator leveraging web standards like WebSockets for full command-line access in both cloud and desktop setups. These tools bridge traditional text UIs with modern web ecosystems, facilitating scalable, browser-native development environments. Text-based user interfaces persist in gaming and social applications, where they offer lightweight, immersive interactions. The libtcod library, developed in the mid-2000s as a C-based toolkit for games, enables of text displays with advanced features like and field-of-view algorithms, supporting true-color consoles for enhanced visual depth in worlds. It remains a staple in contemporary development, as evidenced by ongoing tutorials adapting it for languages like and C++ to create turn-based adventures with dynamic text rendering. In social platforms, 's ecosystem of text bots utilizes command-line-style inputs for interactive experiences, such as text adventure games and simulations that process user commands in chat channels to drive narrative progression. Bots like RuneBot exemplify this by emulating text-based MMORPG mechanics, allowing players to issue commands for actions like combat or exploration within servers. Accessibility applications highlight the enduring value of text UIs for inclusive computing. On systems, the , a free and open-source tool integrated with desktop since the early 2000s, vocalizes text-based content from user interfaces, including terminals and documents, to support visually impaired users through and output. processes screen elements via APIs, reading command-line outputs and form interactions aloud to enable navigation and control in text-heavy environments like shells and editors. Emerging trends in text UIs blend with command-line efficiency, while retro revivals foster niche creativity. The CLI, launched in public preview in September and expanded in the mid-2020s, integrates AI agents into terminals to generate, explain, and execute commands, aiding developers in tasks like and repository management without leaving the text interface. This tool uses large language models to interpret queries and output shell-compatible responses, streamlining workflows in resource-constrained or remote setups. Another notable example is HTTPie, a user-friendly command-line HTTP client written in Python that supports colored output for improved readability. Concurrently, modern revivals of retro computing have renewed interest in text-based adventures, with platforms reimagining 1970s-1980s classics like through web-accessible parsers that emphasize narrative depth over graphics. These efforts, often powered by emulators and open-source tools, appeal to enthusiasts seeking minimalist, imagination-driven interfaces in digital culture.

References

  1. https://web.stanford.edu/class/cs45/lectures/5-text-editors.notes.pdf
  2. https://itsfoss.com/gui-cli-tui/
  3. https://www.unicode.org/L2/L2023/23107-terminal-suppt.pdf
  4. https://invisible-island.net/ncurses/ncurses-intro.html
  5. https://tldp.org/HOWTO/NCURSES-Programming-HOWTO/intro.html
  6. https://pmc.ncbi.nlm.nih.gov/articles/PMC2655855/
  7. https://wiki.debian.org/Aptitude
  8. https://github.com/neovim/neovim
  9. https://users.soict.hust.edu.vn/trungtt/uploads/slides/HCI-L03(en).pdf
  10. https://huichen-cs.github.io/course/CISC3120/18SP/lecture/cisc3120_c11.pdf
  11. https://learn.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences
  12. http://bitsavers.informatik.uni-stuttgart.de/pdf//ansi/X3/X3.004-1986_7-Bit_ASCII.pdf
  13. https://www.columbia.edu/cu/computinghistory/teletype.html
  14. https://ethw.org/ENIAC
  15. https://www-formal.stanford.edu/jmc/history/timesharing/timesharing.html
  16. https://vt100.net/dec/vt_history
  17. https://historyofcomputercommunications.info/section/6.8/Early-Surprises-1969-1970/
  18. https://blog.ansi.org/ansi/ansi-art-ascii-art-iso-standards-x3-64/
  19. https://www.zdnet.com/article/guis-the-computing-revolution-that-turned-us-into-cranky-idiots/
  20. https://arstechnica.com/features/2005/05/gui/
  21. https://bitsavers.computerhistory.org/pdf/datapro/datapro_70/70D-010-20_All_About_CRT_Display_Terminals_Apr1974.pdf
  22. https://bitsavers.computerhistory.org/pdf/datapro/alphanumeric_terminals/Datapro_C25-010_198312.pdf
  23. https://w140.com/tekwiki/wiki/4010
  24. https://www.analog.com/en/resources/technical-articles/fundamentals-of-rs232-serial-communications.html
  25. https://www.serial-port-monitor.org/articles/serial-communication/rs232-interface/
  26. https://bitsavers.org/pdf/dec/terminal/vt100/EK-VT100-UG-001_VT100_User_Guide_Aug78.pdf
  27. http://www.columbia.edu/cu/computinghistory/vt100.html
  28. https://invisible-island.net/xterm/
  29. https://www.chiark.greenend.org.uk/~sgtatham/putty/
  30. https://docs.kernel.org/driver-api/console.html
  31. https://invisible-island.net/xterm/xterm.faq.html
  32. https://invisible-island.net/luit/luit.html
  33. https://invisible-island.net/xterm/xterm.log.html
  34. https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub86.pdf
  35. https://ecma-international.org/wp-content/uploads/ECMA-48_5th_edition_june_1991.pdf
  36. https://invisible-island.net/xterm/ctlseqs/ctlseqs.html
  37. https://unix.stackexchange.com/questions/87246/why-has-the-ansi-3-64-standard-been-withdrawn
  38. https://vt100.net/dec/ek-vt220-rm-001.pdf
  39. https://datatracker.ietf.org/doc/html/rfc854
  40. https://www.iso.org/standard/12782.html
  41. https://man7.org/linux/man-pages/man7/pty.7.html
  42. https://man7.org/linux/man-pages/man3/termios.3.html
  43. https://www.kernel.org/doc/html/v6.1/driver-api/tty/n_tty.html
  44. https://www.gnu.org/software/bash/manual/html_node/History-Interaction.html
  45. https://www.gnu.org/software/bash/
  46. https://www.gnu.org/s/readline
  47. https://zsh.sourceforge.io/Doc/Release/Introduction.html
  48. https://github.com/tmux/tmux
  49. https://man7.org/linux/man-pages/man1/tmux.1.html
  50. https://www.gnu.org/software/screen/manual/screen.html
  51. https://www.theregister.com/2024/09/03/gnu_screen_5/
  52. https://www.x.org/archive/X11R6.7.0/doc/xterm.1.html
  53. https://www.dosdays.co.uk/topics/dos_versions_pt2.php
  54. http://wiki.osdev.org/VGA_Hardware
  55. https://www.computerhope.com/ansisys.htm
  56. https://devblogs.microsoft.com/commandline/windows-command-line-the-evolution-of-the-windows-command-line/
  57. https://devblogs.microsoft.com/commandline/windows-command-line-inside-the-windows-console/
  58. https://learn.microsoft.com/en-us/windows/console/setconsoletextattribute
  59. https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/cmd
  60. https://learn.microsoft.com/en-us/powershell/scripting/whats-new/cmdlet-versions?view=powershell-7.5
  61. https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/
  62. https://wiki.vmssoftware.com/OpenVMS
  63. https://docs.vmssoftware.com/docs/VSI_RMS_Ref_Manual_23Jul19.pdf
  64. https://www.digiater.nl/openvms/doc/ia64-v8.3/opsys/vmsos83/4523/4523pro_027.html
  65. https://vmssoftware.com/about/news/2022-07-14-openvms-v92-for-x86-announced/
  66. https://vmssoftware.com/products/versions/
  67. https://web.stanford.edu/class/ee281/handouts/lcd_tutorial.pdf
  68. https://labs.dese.iisc.ac.in/embeddedlab/uart/
  69. https://busybox.net/about.html
  70. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/fundamentals/configuration/15mt/fundamentals-15-mt-book/cf-cli-basics.html
  71. https://docs.micropython.org/en/latest/reference/repl.html
  72. https://ieeexplore.ieee.org/document/6717794
  73. https://github.com/xtermjs/xterm.js
  74. http://xtermjs.org/
  75. https://theia-ide.org/theia-platform/
  76. https://github.com/libtcod/libtcod
  77. https://www.roguebasin.com/index.php/Complete_roguelike_tutorial_using_C%2B%2B_and_libtcod_-_part_1:_setting_up
  78. https://top.gg/tag/text
  79. https://rune-server.org/threads/runebot-a-runescape-text-based-discord-bot.698754/
  80. https://help.gnome.org/users/orca/unstable/index.html.en
  81. https://www.zdnet.com/article/how-to-use-the-orca-screen-reader-in-linux/
  82. https://github.com/features/copilot/cli
  83. https://github.blog/ai-and-ml/github-copilot/github-copilot-cli-how-to-get-started/
  84. https://github.com/httpie/cli
  85. https://retromash.com/2025/03/17/top-10-retro-revival-trends-in-digital-culture/
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.