ex is a line-oriented text editor originally developed for the Unix operating system by Bill Joy in 1976 as an extension of the earlier ed editor, providing a superset of its commands for creating and modifying text files.^[1] It operates primarily in command mode, where users enter instructions prefixed by a colon (:) to manipulate lines of text within an edit buffer, with changes saved to files only upon explicit commands like write.^[2] While ex supports additional screen-oriented modes—open for simple display and visual for full-screen interaction—these are more fully realized in its derivative, the vi editor, making ex the foundational line-editing component of vi.^[3][2] Standardized as part of the POSIX specification based on implementations from Berkeley Software Distribution (BSD) and System V Unix, ex includes configurable options such as autoindent for automatic line indentation, shiftwidth (defaulting to 8 spaces) for tab expansion, and wrapscan for circular search behavior.^[2] Key commands enable precise text operations, including substitution with enhanced basic regular expressions (supporting anchors like \< and \>), buffer execution via @, and scrolling with Control-D.^[2] Command-line invocation options like -r for recovering interrupted sessions, -R for read-only mode, and -s for suppressed output in batch scripting enhance its utility for both interactive and automated editing tasks.^[1][3] Though largely superseded by graphical and improved modal editors like Vim in modern workflows, ex remains influential in Unix-like systems for its efficiency in line-based processing and as the underlying engine for vi, demonstrating the enduring impact of early Berkeley innovations on text manipulation tools.^[1]

Overview and Development

Origins in Unix Editing Tradition

The development of early line-oriented text editors in Unix began with ed, created by Ken Thompson and Dennis Ritchie at Bell Labs in the early 1970s as a core component of the nascent operating system.^[4] Designed for efficient manipulation of text files on limited hardware like the PDP-11, ed established the model of command-based, line-addressing editing that became standard in Unix environments, prioritizing compactness and scriptability over visual interaction.^[5] By 1975, as Unix spread beyond Bell Labs, enhancements to ed emerged to address its limitations in interactive use. George Coulouris at Queen Mary College, London—the first UK site to install Unix in 1973—developed em, an improved editor that extended ed's commands with on-screen feedback for single-line edits via video display units (VDUs), enabling more responsive editing while maintaining backward compatibility.^[6][7] This innovation catered to the growing demand for editors that could leverage emerging terminal hardware in academic settings. In 1976, Charles Haley implemented an ed clone at the University of California, Berkeley, which incorporated modifications for better performance and extensibility, serving as the foundational codebase for subsequent developments.^[8] Haley's version addressed inefficiencies in ed's handling of larger files and complex operations, reflecting the iterative improvements typical of early Unix tool evolution. The mid-1970s Unix expansion into academic and research environments amplified the need for more powerful line editors, as universities adopted the system for teaching and experimentation on affordable minicomputers, fostering a collaborative ecosystem where tools like ed were refined to support programming and documentation tasks amid increasing user concurrency and shared code distribution.^[5][9] Bill Joy later enhanced em to create ex, building on these foundations.

Creation and Key Milestones

In 1976, while a graduate student at the University of California, Berkeley, Bill Joy, in collaboration with Charles Haley, enhanced the em text editor—originally developed at Queen Mary's College in London—into ex, creating a more advanced line-oriented editor compatible with the ed editor but featuring improved high-speed terminal support and additional functionalities.^[8] This work built on modifications to ed, incorporating ideas from Joy, Haley, and a variant used at UCLA, with initial versions completed by September 1976.^[8] The first public release of ex occurred on March 9, 1978, as a key component of the First Berkeley Software Distribution (1BSD), an add-on to Version 6 Unix that also included a Pascal compiler developed by Joy and others.^[10] Written in the C programming language from its inception to ensure portability across Unix systems, ex was updated and redistributed in subsequent Berkeley releases, including 2BSD in May 1979—which added tools like the C shell—and 4BSD in November 1980, which introduced virtual memory and further refined the editor for broader Unix adoption.^{[11][12][13][14]} The name "ex" is speculated to derive from "EXtended" (as an extension of ed) or "eXperimental," though no definitive source confirms its origin.^[8] Ex saw early adoption across Unix variants through BSD distributions, solidifying its role in establishing standards for line-oriented text editing in academic and research environments.^[12]

Relation to Other Editors

Predecessors like ed and em

The ed text editor, authored by Ken Thompson at Bell Labs, emerged in 1969 as one of the foundational programs for the nascent Unix operating system. As a line-oriented editor, it processed text one line at a time through a command-based interface, enabling operations such as insertion, deletion, and substitution via concise directives. Key features included numerical addressing for targeting specific lines or ranges (e.g., 5p to print line 5 or 1,$d to delete the entire buffer) and global commands like g/pattern/command to apply actions across all matching lines, fostering efficient scripted editing on resource-constrained hardware. Its minimal interface eschewed visual displays, relying instead on explicit print commands (p) to output lines, which aligned with the era's teletype terminals but prioritized compactness over user-friendliness.^[15][16] Despite its pioneering role and influence on subsequent tools, ed exhibited notable limitations that hindered interactive use, particularly for novices or complex tasks. The absence of on-screen feedback meant users edited "blindly," often printing lines repeatedly to verify changes, while substitution commands (s/old/new/) lacked advanced pattern matching beyond basic regular expressions, complicating bulk replacements. Recovery features were rudimentary, offering only a single-level undo (u) for the most recent change and no robust mechanisms for session recovery after crashes or interrupts, leading to potential data loss in prolonged sessions. These shortcomings, exacerbated by ed's single-file focus and terse error reporting, prompted calls for enhancements to support more dynamic editing workflows.^[17][18] In 1975, George Coulouris at Queen Mary College, London, addressed many of ed's usability gaps with em, an upward-compatible extension designed for display terminals installed on their Unix system since 1973. em preserved ed's core syntax and line-oriented paradigm but introduced keystroke-level interaction in raw terminal mode, allowing users to visually edit the current line character by character with immediate screen updates, thus mitigating blind editing. This innovation, dubbed "editor for mortals" to contrast ed's perceived austerity, improved single-line manipulation without altering ed's command structure, enabling seamless transition for existing scripts. While specific details on advanced substitutions remain tied to ed's framework, em's design emphasized practicality on limited hardware, laying groundwork for broader interactivity.^[7][15] ex directly inherited ed's line-oriented model, including its addressing schemes and global command syntax, ensuring backward compatibility for automated editing tasks. However, by building upon em's enhancements—particularly the visual single-line mode and refined terminal handling—ex achieved greater usability for multi-file operations, such as switching buffers with :e filename and editing across sessions without losing ed-style precision. This evolution transformed the lineage into a more versatile tool while retaining the minimalist ethos of its predecessors.^[15]

Integration and Evolution with vi

In 1976, Bill Joy, a graduate student at the University of California, Berkeley, extended the line-oriented ex editor by adding a full-screen visual interface, thereby creating vi as a superset that combined ex's command capabilities with interactive screen-based editing.^[19] This integration allowed vi to leverage ex's robust engine while introducing cursor movement and visual feedback suited to the era's terminals, such as the Lear Siegler ADM-3A.^[15] Within vi, ex commands remain fully accessible through a colon (:) mode, enabling users to switch seamlessly between visual editing and ex's line-oriented operations for tasks requiring precise addressing or batch processing.^[20] For instance, entering : followed by an ex command like substitute executes it on the current buffer, preserving ex's syntax for complex edits without leaving the vi session. This design ensured backward compatibility and flexibility, as vi was architecturally a thin wrapper around ex's core, invoking it in visual mode upon launch.^[15] vi was first publicly released in the Second Berkeley Software Distribution (2BSD) in May 1979, where it was bundled alongside ex, allowing direct invocation of either editor or starting ex from within vi.^[15] This bundling marked vi's transition from an experimental extension—rooted briefly in ex's origins from predecessors like ed and em—to a standard Unix tool, with ex serving as the foundational layer.^[19] The architectural fusion of ex and vi has endured in modern implementations, where ex persists as the underlying engine accessible via ex mode in editors like nvi and Vim, maintaining compatibility with POSIX standards and historic behaviors.^[21] In systems such as FreeBSD, nex/nvi provides bug-for-bug compatibility with the original 4BSD ex/vi, ensuring ex's command syntax remains integral for scripting and non-interactive use.^[21]

Invocation and Basic Usage

Command-Line Syntax and Options

The ex text editor is invoked from the command line using the POSIX-specified synopsis: ex [-rR] [-s|-v] [-c command] [-t tagstring] [-w size] [file...].^[22] This syntax allows users to specify options for recovery, mode selection, initial actions, and file handling, with optional file arguments provided at the end.^[22] By default, ex starts in its line-oriented command mode unless the -v option is used to enter visual mode, which invokes the screen-oriented vi interface.^[22] Key command-line options from the POSIX standard control the editor's startup behavior and environment:

• -r: Enables recovery mode for specified files following an editor or system crash; if no files are named and neither -t nor file operands are provided, it lists all recoverable files and exits.^[22]
• -R: Sets the editor to read-only mode, preventing file modifications.^[22]
• -s: Prepares the editor for non-interactive (batch or script) use by suppressing all prompts and diagnostic messages, ignoring environment variables like TERM and EXINIT, and assuming the terminal does not support open or visual modes while disabling features like autoindent.^[22]
• -v: Starts the editor in visual mode, equivalent to invoking vi directly.^[22]
• -c command: Executes the specified ex command(s) immediately after loading the first file into the buffer; multiple -c options can be provided, and they are processed in sequence.^[22]
• -t tagstring: Edits the file containing the specified tag (as found in a ctags generated tags file) and positions the cursor at that tag; only one such option is permitted.^[22]
• -w size: Sets the window editor option to the given positive integer size, which determines the number of lines displayed in visual mode.^[22]

Certain implementations provide additional options, such as:

• -l: Enters Lisp mode, which adjusts options suitable for editing Lisp code, such as setting lisp and showmatch.^[23]
• -x: Enables encryption for the editing session, prompting for a key unless otherwise configured.^[24]
• -C: Enables encryption using the implementation-defined default algorithm (historically the version 1 crypt utility).^[24]

When multiple files are specified as operands (e.g., ex file1.txt file2.txt), ex loads them into an argument list and begins editing the first file; subsequent files can be accessed and cycled through using in-editor commands like :n (next) and :rew (rewind).^[22] If no files are provided, ex starts with an empty buffer awaiting input.^[22] Options must precede file operands, and mutually exclusive flags like -s and -v cannot be combined.^[22]

Initial Session and File Handling

Upon invocation, ex initializes an empty edit buffer if no file is specified, or loads the contents of the provided file into the buffer, setting the current pathname accordingly.^[25] In many implementations, the editor then displays the file status, including the filename, total line count, and current line position, before entering command mode with a colon (:) prompt for user input. During this startup sequence, ex executes initialization commands from the EXINIT environment variable or the user's $HOME/.exrc file if present and accessible, followed by a local .exrc if the exrc option is enabled.^[25] Basic buffer management in ex relies on core ex commands to handle file interactions within the session. The :e[dit] command replaces the current buffer contents with a new file, prompting a warning if the buffer is modified unless overridden with !; it sets the current line to the last line of the new file and the column to the first non-blank character.^[26] To save changes, :w[rite] outputs the buffer to the current or specified file, reporting the number of lines and characters written, and requires ! to force overwrite in read-only mode.^[25] Session exit uses :q[uit], which terminates only if the buffer is unmodified or no further files remain in the argument list, with ! forcing exit and discarding changes; :wq or :x[it] combines writing and quitting in one step.^[23] For sessions involving multiple files provided as arguments, ex maintains an internal argument list tracking them in sequence. The :args command displays this list, enclosing the current file in brackets [].^[26] Navigation uses :next to advance to the subsequent file, optionally updating the list with new files and requiring ! if the buffer is modified, while :prev moves to the previous file in the list.^[25] Error recovery in ex leverages the -r option to restore sessions interrupted by crashes or signals, scanning for preserved temporary files and listing recoverable ones if invoked without a filename; upon recovery, the buffer is marked as modified to prompt saving.^[23] This mechanism uses system mail notifications to alert users of recoverable files post-interruption.^[26] Session termination in Unix environments allows multiple independent ex instances to run concurrently, each managing its own buffer and file associations without interference, though shared files may require coordination to avoid conflicts during writes.^[25] Quitting with :q or variants ends only the current session, leaving other processes unaffected.^[23]

Core Features and Commands

Line-Oriented Editing Operations

Ex operates as a line-oriented text editor, where all editing commands target specific lines in the buffer rather than character positions, emphasizing precision through explicit addressing and command-line interactions. This paradigm, rooted in early Unix editing tools, allows users to manipulate text without visual cursor movement, making it suitable for scripting and batch processing. Changes are applied to an in-memory edit buffer and persist only until explicitly written to a file.^[27] Addressing in ex uses a flexible syntax to specify single lines, ranges, or patterns for operations. Absolute line numbers like 5 target the fifth line, while relative addressing employs symbols such as . for the current line, $ for the last line, and % to denote the entire file (equivalent to 1,$). Ranges are formed as 3,7 to select lines from the third to the seventh, and searches integrate via /pattern/ for forward matching or ?pattern? for backward, with offsets like +2 or -1 adjusting from a base address. This system ensures targeted edits without ambiguity.^[27] Basic line manipulation commands include d to delete addressed lines (defaulting to the current line if unspecified), which removes them from the buffer and copies to an unnamed yank buffer; the current line then advances to the next undeleted line or the file end. The y command yanks (copies) lines to a named or unnamed buffer without altering the buffer, preserving the current line position for subsequent pastes via p or P. Printing with p displays the addressed lines, setting the current line to the last printed one. Undo functionality is provided by u, which reverses the most recent change, such as a deletion or insertion, and repositions the current line to the affected area. These operations form the core of ex's non-destructive editing workflow.^[27] Insertion commands enable adding text relative to addressed lines. The i command inserts text before the specified line (or current line), entering input mode until a line containing only a period (.) is entered; the current line shifts to the last inserted line, with automatic indentation matching the previous line's style if applicable. Conversely, a appends text after the addressed line, similarly ending input mode with . and setting the current line to the final appended line, often indenting based on the following line. Addressing insertion points can incorporate searches, such as ./pattern/i to insert before the next matching line, supporting multi-line additions seamlessly.^[27] Movement within the file relies on search commands integrated into addressing. The /pattern/ directive searches forward from the current line for the next match, setting it as the new current line, while ?pattern? searches backward. These can chain with addresses, like .,/end/ for a range to the forward match. The :set wrapscan option, enabled by default, allows searches to wrap around from the file end to the beginning (or vice versa), ensuring comprehensive navigation without manual resets. Ex mode is accessible from the vi editor via the colon (:) command prefix, bridging line-oriented and visual editing.^[27]

Addressing and Substitution Mechanisms

Ex's substitution command provides a mechanism for replacing text patterns within specified line ranges, enabling efficient text transformation. The basic syntax is [range]s/pattern/replacement/[flags], where range defines the lines to operate on (defaulting to the current line), pattern is a basic regular expression (BRE) matching the text to replace, and replacement is the substituting string. For instance, :%s/old/new/g performs a global replacement of "old" with "new" across the entire file (% denotes lines 1 to $). This command builds on line addressing by allowing search-based ranges, such as /regexp/ to target the next line matching the regular expression forward from the current position, or ?regexp? for backward searches.^[25] Flags modify the substitution behavior: g applies the replacement to all non-overlapping matches on each line rather than just the first, while c prompts for confirmation before each substitution, displaying the affected line with markers for the matched pattern. Case-insensitive matching is achieved globally via the ignorecase editor option (:set ignorecase), which affects all regular expressions used in substitutions and searches; there is no dedicated i flag for the s command in the standard. Advanced features include escaping special characters in patterns with \ (e.g., \. to match a literal period) and using \& in the replacement string as a backreference to the entire matched pattern, allowing constructions like s/pattern/\&-modified/ to append "-modified" to each match.^[25][26] For broader pattern-based processing, ex offers global commands that apply other commands selectively. The g command, with syntax [range]g/pattern/command, executes the specified command on all lines within the range (default 1,$) that match the [pattern](/page/Pattern); multiple commands can be chained with escaped newlines. Conversely, `v/pattern/command` applies the command to lines not matching the pattern. An example is `g/error/p`, which prints all lines containing "error", or `g/^\s*$/dto delete blank lines. These commands integrate with substitution, such asg/old/s//new/g`, to replace "old" with "new" only on lines already matching "old".^[25] Substitutions primarily operate on the main edit buffer but can incorporate content from auxiliary buffers. Ex maintains an unnamed buffer for recent deletions or yanks and 26 named buffers (a-z) for storing text via commands like d a (delete to buffer a) or y a (yank to buffer a). To substitute in such content, it can be inserted into the edit buffer using put a (or pu for the unnamed buffer), processed with s, and then optionally yanked back to another buffer if needed; direct substitution within named buffers is not supported in the standard, though some implementations extend this via buffer-specific commands. Addressing in these contexts uses the same mechanisms, with ranges applied post-insertion.^[25][26]

Advanced Capabilities and Standards

Scripting and Encryption Features

Ex provides extensibility through macro definitions, allowing users to map key sequences to sequences of commands, primarily for use in visual mode. The :map command defines such mappings, where a left-hand side (lhs), typically a single character or function key, triggers the execution of the right-hand side (rhs) command string upon input. For instance, :map x i abc maps the 'x' key to enter insert mode and append "abc" before returning to command mode. This feature, introduced in early versions, facilitates automation of repetitive tasks and is detailed in the editor's reference manual.^[28] Abbreviations complement macros by enabling automatic text expansion during input mode. The :ab command, or :abbrev, associates a full word with a shorter form, replacing the abbreviation with the expansion when the former is typed as a complete word. An example is :ab teh the, which corrects common typos like "teh" to "the" on the fly. These abbreviations apply in visual mode's insert operations and enhance typing efficiency without altering command sequences. Substitution commands, such as :s/old/new/, can also be incorporated into macro definitions or scripts for pattern-based replacements.^[29] The -s flag enables non-interactive script execution, reading commands from a file or standard input while suppressing diagnostic output and prompts, making it suitable for batch processing. When invoked as ex -s scriptfile, the editor processes the file's ex commands sequentially on the target buffer, ideal for automated editing workflows. This mode ensures silent operation, with errors potentially halting execution unless handled within the script.^[29] Encryption features in ex protect file contents using a simple key-based cipher compatible with the crypt(1) utility. The -x option prompts for a key upon startup, encrypting the buffer if writing or decrypting if reading an encrypted file; the same key must be used for both operations. Mid-session, the :X command sets or changes the encryption key, applying it to subsequent writes, while -C forces encryption mode assuming the file is already encrypted, simulating the :C command for compatibility. These mechanisms, active only when specified, store keys in memory and use a transformed variant for temporary files to maintain security during edits. However, the algorithm provides basic protection and is vulnerable to known attacks if the key is compromised.^[29] Lisp mode, invoked with the -l option, configures ex for editing Lisp source code by enabling specialized indentation and navigation. It activates autoindent with a shiftwidth of 8 spaces for consistent code formatting, sets showmatch to highlight matching parentheses, and adjusts movement commands like ( and ) to treat Lisp forms as units rather than sentences. Additionally, it supports error jumps, allowing quick navigation to compilation errors via integration with tags or error messages, streamlining debugging in Lisp environments. These settings, tailored for structured programming, persist for the session unless manually overridden.^[28]

POSIX Compliance and Modern Implementations

The ex text editor was standardized as part of IEEE Std 1003.2-1992, known as POSIX.2, which mandated a core set of line-oriented editing commands including edit for loading files into the buffer and substitute for pattern-based replacements using regular expressions, along with options such as -r for recovering files after a crash.^[22] This standardization ensured portability across Unix-like systems by defining the editor's invocation syntax, buffer management, and essential operations like addressing lines and global substitutions.^[22] The POSIX.2 specification drew from the original Berkeley Software Distribution (BSD) implementation of ex, positioning it as the reference for compliant behavior, including support for options like -s for script mode and -c for initial commands.^[22] The original BSD ex, first appearing in 1BSD in 1977 and refined through versions up to 4.4BSD, serves as the foundational reference implementation for POSIX compliance.^[30] Contemporary BSD derivatives maintain this lineage: FreeBSD uses nex/nvi, a POSIX-compliant reimplementation introduced in 4.4BSD to replace the original while preserving core ex functionality.^[30] Similarly, OpenBSD employs a customized version of nvi, forked around 1996 and enhanced over decades to align with POSIX.2 requirements, including line addressing and substitution mechanisms.^[31] These implementations ensure ex remains available as a lightweight, standards-based tool in base systems without licensing encumbrances from the original code.^[30] Several modern variants extend ex's POSIX foundation while adding enhancements for broader use cases. nvi (new vi), developed by Keith Bostic and released in 1994 as part of 4.4BSD, provides a clean reimplementation of ex with improved performance and modularity, serving as the basis for many BSD ports. Vim's ex mode, invoked via ex or the :visual command, offers full POSIX.2 compatibility alongside extensions, allowing seamless line-oriented editing in a feature-rich environment.^[32] Lightweight options include elvis-tiny, a minimal vi/ex clone derived from the 1991 Minix elvis, optimized for resource-constrained systems like embedded devices.^[33] BusyBox's integrated vi/ex applet provides a compact, POSIX-approximate implementation suitable for minimalistic Linux distributions, supporting core commands in under 100 KB.^[34] Cross-platform ports enhance ex's accessibility beyond Unix. GNU/Linux distributions often include nvi or Vim's ex mode, with Debian and Ubuntu packaging nvi for POSIX fidelity.^[35] For Windows, Cygwin delivers ex through its vim or nvi packages, enabling line-oriented editing in a POSIX-emulated environment via command-line invocation.^[36] These ports maintain compatibility with POSIX.2 mandates, such as recovery options and substitution flags, while integrating with host file systems. Post-2000s POSIX-compliant ex variants have incorporated updates for contemporary needs, including Unicode handling and large file support. Vim added native UTF-8 and multibyte character support in version 6.0 (2001), allowing ex mode to process international text without corruption. nvi forks like nvi2 and OpenVi, used in modern BSDs, enable UTF-8 input and display for globalized workflows, extending the original ASCII-limited design.^[37] Regarding large files, implementations such as Vim and nvi now handle gigabyte-scale buffers efficiently through memory-mapped I/O and lazy loading, surpassing the original ex's constraints on 1980s hardware while adhering to POSIX buffer semantics. These enhancements ensure ex remains viable for scripting and batch processing in diverse, data-intensive environments.