In the sprawling landscape of modern development tools, where graphical interfaces and AI-assisted coding dominate, one ancient text editor often elicits confusion: ed(1). The mastermind behind the @ed1conf social media accounts frequently encounters the question: Why ed? Yet beneath its cryptic interface lies a surprisingly versatile tool that continues to offer distinct advantages for developers navigating complex environments.

Ubiquity: The Ultimate Fallback

When your preferred $EDITOR vanishes—whether due to permission restrictions, disk space constraints, or minimal recovery environments—ed(1) remains. As a cornerstone of the POSIX standard, it’s preinstalled on virtually every Linux, BSD, and macOS system. This universal presence makes it the ultimate safety net. As the author notes: "Sometimes your favorite $EDITOR is installed, sometimes it's not... But if you know ed, nearly every Linux/BSD/Mac has it installed." This reliability proves invaluable when working with embedded systems or recovery media where storage is measured in kilobytes, not megabytes.

The Last Resort: When It’s the Only Option

"At $DAYJOB[-1] the Linux-based router needed configuration changes the web interface didn’t accommodate... So a quick terminal connection later (telnet, sigh), I discovered that ed was the only editor available."

Real-world scenarios often strip away modern conveniences. The author recounts experiences with legacy routers and ruggedized DOS-based PDAs where full-screen editors failed—either due to screen rendering issues or keyboard real estate constraints. Installing ed(1) transformed workflows, cutting file-editing iterations from 15-20 minutes to 3-5 minutes. Even cloud platforms like Heroku default to ed(1) for live server edits, while MUD games and BBSes frequently employ its line-editing paradigm. In these constrained environments, ed(1) isn’t just an option—it’s the only viable solution.

Technical Resilience: Beyond Broken Terminals

Modern development assumes stable terminals and keyboards. But when $TERM settings get corrupted, function keys misbehave, or network latency spikes, ed(1)’s ASCII-based commands shine. Since all operations use stdin/stdout and rely solely on printable characters, it functions even when arrow keys or escape sequences fail. This makes it invaluable for:
- Broken terminal sessions: When reset fails or termcap databases are corrupted.
- Low-bandwidth connections: Satellite uplinks or 300-baud serial links where screen repainting overhead cripples other editors.
- Scriptable automation: Commands piped from stdin enable programmatic file manipulation, ideal for CI/CD pipelines or emergency fixes.

Accessibility and Workflow Integration

Unlike screen-hogging GUI editors, ed(1) preserves shell output in the scrollback buffer. This allows developers to reference previous command results—like SQL query outputs in psql or mysql—while editing inline. Its serial interface also makes it uniquely accessible for screen readers like yasr or speakup, enabling blind text editing. As the author observes: "I find this particularly useful when using \e in psql or mysql if my $EDITOR is set to ed."

The Grey-Beard Factor

Beyond practicality, ed(1) carries cultural capital. Mastery signals fluency in Unix history and command-line philosophy—a stark contrast to "cert-only" knowledge. It’s a conversation starter and a testament to understanding foundational tools that underpin modern systems. As the author quips: "There’s a small measure of grey-beard prestige that comes with using an editor that baffles so many people."

In an era of increasingly complex toolchains, ed(1) reminds us that simplicity and resilience have enduring value. Whether you’re debugging a router at 3 AM, scripting across a satellite link, or simply want to impress your colleagues with Unix lineage, this 1976 relic remains unexpectedly potent. Its lessons in minimalism and ubiquacity are more relevant than ever.

Source: TheChases Blog - Why ed(1)?