A Deep Dive into the ed Text Editor

There's a long-running joke, a shibboleth tossed at new
users, that "ed is the standard editor". This is
often said with a wry smile, as ed is notoriously
user-unfriendly. Its default state is a blank line, it offers
no prompt, and its only error message is a single, cryptic
?.

But the secret, and the reason the joke has such staying
power, is that it's fundamentally true. For early Unix, ed
was the standard text editor. To this day, it
remains a required component of the POSIX standard, meaning
it's present on virtually every Unix-like system on
earth.

In an age of "over-engineered IDEs" and "kitchen sink"
configurations, ed represents a different path. Its brutal
simplicity isn't a flaw; it's a design philosophy. This deep
dive will explore the power and elegance of ed.

For the uninitiated, ed's a line-oriented and modal text
editor. This means you don't see or edit a full screen of
text. You operate, by default, on one line at a time using a
precise set of commands. It's this command-driven nature that
unlocks its true potential.

To understand ed, one must be transported to August 1969
at AT&T Bell Labs. Ken Thompson, a co-author of Unix, was
working on a PDP-7 and developed the three primordial
elements of this new OS: the assembler, the editor, and the
shell. That original editor was ed.

The "user interface" for this new system wasn't a glass
video monitor. Instead it was a Teletype Model 33, a slow,
noisy mechanical printer equipped with a keyboard. The
limitations of this machine shaped ed's design. The teletype
printed only 10 to 15 characters per second - so slow that
even the simplest confirmation message would waste time and
paper. It also printed output line by line onto a physical
roll of paper, making every line permanent once produced.

These constraints led to design choices that can feel
cryptic today but were ingenious optimizations at the time.
Ed's silent because each unnecessary character was costly; no
prompt or default feedback meant the machine avoided wasting
both seconds and paper. Scrolling was impossible, since the
Teletype had no display - only a one-directional roll of
paper. To see the past you only need to look at the physical
piece of paper. Editing had to occur line by line, operating
on an invisible copy of the file in memory. Even the infamous
"?" error was an act of efficiency: one character that
communicated failure in the most compact way possible. The
later GNU ed option that prints verbose errors is a luxury
never imagined in its original environment.

Ed's design isn't user-hostile; it's resource-friendly, an
elegant tool perfectly tailored to its constraints.

Its technical lineage is equally foundational. Ed was
inspired by QED (Quick Editor) from UC Berkeley, Thompson's
alma mater. Thompson's adaptation of QED - and its successor
ed - were notable for introducing regular expressions to Unix
text editing. Dennis Ritchie refined this capability into
what became the definitive ed, and from it emerged the DNA of
Unix text-processing philosophy. Ed's the direct ancestor of
tools like grep and sed, and the concept of text streams as a
universal interface in Unix begins here.

An Interactive ed Session

Let's face the void. When you launch the editor by typing
ed at your prompt, you are greeted with... nothing. The
editor's running, silently waiting in command
mode.

Before doing anything else, modern GNU ed provides two
"magic" commands that make it usable for beginners.

1. Type P (uppercase) and press Enter. This toggles a
prompt, so you know ed is in command mode. The default
prompt is an asterisk (*).

2. Type H (uppercase) and press Enter. This toggles
verbose help for errors. Now, the infamous ? will be
replaced with a helpful message, such as "Unknown
command."

Let's try a complete "Hello, World" workflow.

1. Enter Input Mode: We start in command mode. To add
text, we must enter input mode. Type a (for "append") and
press Enter.

2. Add text: ed is now in input mode, ready to append text
after the current line (which is line 0 in an empty file).
Let's type our text: Hello, world.

3. Return to Command Mode: To stop inputting, type a
single period on a line by itself and press Enter. This is
the most common point of confusion for new users.

4. View the Buffer: The text isn't yet in a file; it's in
a memory buffer. To see what's in the buffer, we use the p
(print) command. A common shortcut is ,p (comma-p), which
is shorthand for 1,p - meaning "from line 1 to the last
line, print".

5. Save the Buffer (Write): The w (write) command saves
the buffer to a file. Let's write to hello.txt by entering:
w hello.txt. ed helpfully responds with the number of bytes
written to the file.

6. Quit: The q (quit) command exits the editor.

The mental model is simple but rigid. ed has two
modes.

• Command Mode: The default, where you
issue commands like a (append), i (insert before), c
(change), s (substitute), w (write), and q (quit).

• Input Mode: Entered via a, i, or c. In
this mode, you can only type text. You cannot
edit. You must return to command mode to perform any edits.
This is a direct relic of the teletype, where you couldn't
move a cursor up to fix a typo. You had to finish your line
and then issue a new command to change it.

Unlocking the Power: From Lines to
Programs

The true power of ed isn't in appending text, but in its
sophisticated line addressing. Every command can be prefixed
by an address (a line number, or range) to operate on.

• . : The current line.

• $ : The last line in the buffer.

• n : A specific line number (e.g., 3p prints line
3).

• n,m : A range of lines (e.g., 1,5p prints lines
1-5).

• , or % : A shortcut for the entire file (1,p or
1,%).

• /regexp/ : The next line after the current
line that matches the regular expression. This is
addressing by searching.

This addressing system turns three simple commands into a
powerful toolkit.

1. s (Substitute)

This is the find-and-replace command. Its syntax is
[address]s/regexp/replacement/[flags].

• Example: *%s/foo/far/g

• Translation: "From line 1 to the last
line, substitute (s) the regular expression foo with the
text bar, and do it globally (g) on each line
(i.e., replace all instances, not just the first)".

• In the replacement string, & (ampersand) refers to
the entire matched text.

2. g (Global)

This is the single most powerful command in ed. It's not
just a command; it's a control structure. The syntax is
[address]g/regexp/command(s).

• Translation: "For every line in the
given address range (defaulting to the whole file) that
matches /regexp/, execute the following
command(s) on that line".

• This is a foreach loop. It's programming.

• Example: g/DEBUG/d

• Translation: "For every line in the
file containing the text "DEBUG", execute the d (delete)
command." This deletes all debug lines from a file.

3. v (Inverse Global)

This is the counterpart to g. The syntax is
[address]v/regexp/command(s).

• Translation: "For every line in the
given address range that does NOT match
/regexp/, execute the following command(s)". This is the
equivalent of grep -v.

• Example: v/FINAL/d

• Translation: "Delete all lines
except those containing "FINAL"."

These can be combined. A command like
g/config_option/s/false/true/ translates to: "First, find (g)
all lines containing config_option. Then, only on those
lines, substitute (s) the first instance of false with
true".

This g command is the key to all of Unix text processing.
The ubiquitous grep utility isn't a random name. It's the
literal ed command g/re/p. The command
global/regular
expression/print (find all
lines matching a pattern and print them) was such a typical
ed use case that Ken Thompson extracted it into a standalone
program. ed isn't just an editor; it's the progenitor of the
Unix toolbox.

The ed Command and Addressing
Reference

ed's history's fascinating, but why learn ed when we have
emacs, vi, nano, and more?

The answer is that ed isn't for interactive, day-to-day
writing. Its modern role is as a powerful, silent, and
reliable scripting tool.

When a shell script needs to modify a file, most people
reach for sed -i (the "in-place" flag). This is, however,
often the wrong choice.

• sed is a stream editor. It's designed
for one-pass transformations on data in a
pipeline.

• ed is a file editor. It's designed to
load a file into a buffer, operate on it, and save it.

The sed -i flag (on GNU sed) is a hack. It doesn't edit
"in-place." It works by creating a new temporary
file and then replacing the original file with
it. This operation is problematic: it breaks hard links, can
fail if another process has the file open, and can create
issues with file permissions.

ed performs a true in-place edit. It opens the
file, reads it into its buffer, performs all operations in
memory, and then, on a w command, writes the buffer's
contents back into the original file. For scripts
that need to robustly and atomically edit a configuration
file, ed's the more correct and more reliable tool.

Furthermore, ed is its own REPL (Read-Eval-Print-Loop).
Debugging a complex sed script's a nightmare of trial and
error. With ed, you can interactively load a file, build your
complex command (g/foo/?bar?s/baz/qux/g), test it with p,
undo it with u, and perfect it. Once it's proven, you copy
that command into your script.

ed can be "driven" from a shell script in two main
ways:

Example 1: Using printf and a pipe

This script inserts a new line at the top of a config
file.

Add a new line at the beginning of a file

CONFIG_FILE="/etc/my.conf"

NEW_LINE="options=new_value"

• s suppresses output

1i = Insert at line 1

. = Exit input mode

w = Write

q = Quit

printf '%s\n' '1i' "NEW_LINE" '.' 'w' 'q' \

| ed -s "CONFIG_FILE"

Example 2: Using a Here-Document

This is more readable for complex edits, like changing a
value.

Find and replace a value in a config file

This will change 'DEBUG=true' to 'DEBUG=false'

ed -s /etc/app.conf <

H

g/DEBUG=true/s//DEBUG=false/

w

q

EOF

The second modern use case is as your safety net.

The Scenario: Your machine fails to boot.
It drops you into a single-user recovery mode. You discover
the /usr partition (which might be on a failed disk or a
failed network mount) isn't mounted.

The Problem: Where do vi, vim, nano, and
emacs live? They all live in /usr/bin. They're gone.

The Solution: ed lives in /bin. It's tiny
(often and has almost no dependencies. It will be
there. ed is the only editor you can count on to fix
your /etc/fstab or a broken init script when your system is
truly broken.

The "I'll just use vi" argument's flawed. vi is the editor
for healthy systems. ed is the editor for
broken ones. Learning the ten basic commands - a, i,
d, p, w, q, H, P, , and s - isn't a trivial pursuit; it's an
emergency toolkit.

ed has quite the legacy. The entire lineage of modern
terminal editors flows from it: From ed (Ken Thompson, 1969)
to ex ("extended ed," Bill Joy, 1976) to vi (the "visual"
mode for ex, Bill Joy, 1976) to vim ("Vi Improved," Bram
Moolenaar, 1991).

This lineage holds one final, profound secret. If you're a
vi or vim user, you are already an ed user. You
don't know it. When you are in vim and type : (colon) to
enter command-line mode, you are not simply entering a
"command." You are dropping down into ex mode. And ex is, for
all intents and purposes, a superset of ed.

Every "ex command" you run - :%s/foo/bar/g, g/re/d, :w, :q
• isn't a vi command. It's an ex command, using the exact
syntax, grammar, and philosophy of ed.

Learning ed isn't about mastering an "obsolete" editor.
It's an archeological dig that reveals the living-fossil DNA
inside the tools you use every day. It's about learning the
root language of text editing.

ed's the purest expression of the Unix philosophy. It does
one thing, it does it well, and it does it with a "brutal
elegance" born of necessity. It teaches us that minimalism
isn't about a lack of features; it's about the elegance of
having just enough. In an era of digital excess, ed
isn't just a tool. It's a history lesson and a design
philosophy, waiting for you on a blank line.

Copyright © 2025 Jason Self. Unless otherwise noted
material on this site is licensed under the GNU General Public
License as published by the Free Software Foundation, either
version 3 of the License, or (at your option) any later
version. A copy of the license is included at gpl-3.0.shtml. Please copy and
share.