s/sed/ed

ed is a stupid simple text editor. \ sed is a nice streaming text processing tool. \ Why would one even want to use ed for anything, let alone for text processing if there’s sed? assets/sed-ed.png Digital thumbnail with handwritten text on it. \ The text in the center says “s/sed/ed”. \ Asubstitution command seplacing “sed” with “ed” in the given text. \ In the corners, “a Artyom Bologov .” and “a aartaka.me .” are written in dark-red curvy letters. \ These are mimicking the append command from ed, adding “Artyom Bologov” and “aartaka.me” to the text. IMG(IMAGE, IMAGE_ALT)

This post starts with holding a grudge: Posix regular expressions are extremely hard to get wrong? Uh... Have you really written any? Sounds like you might not really know either Posix or PCRE.

Yes, I’ve written some regular expressions. I made a compiler from Modal to ed, made as an ed script. I implemented Wisp syntax preprocessor for Scheme, the only Wisp implementation besides the reference by Arne Babenhauserheide. Most of 100 RosettaCode entries for ed are completed by me, and I created ed category in the first place.

... come again? ed????? Why are you using such an antiquated editor? Why are you writing scripts for it? It wasn’t even intended for scripting, right? There’s sed for scripting, so just use sed!

No. I stay with ed, because it is

, BRE specification fits on two screens of text

Feature-complete.
More powerful than sed.

But I guess I have to list all the things that sed misses and ed has. If only to convince myself that I need ed after all. So...

Interactive: I Want to Test Things Out

The difference between ed and sed is akin to the interpreted/compiled language difference. You have to run the whole sed script to see the result. While with ed, you can fool around, test regex, and CD(u)ndo them. I use ed as a regex playground before integrating the regex into my projects, like Reb, my regex-heavy Brainfuck toolkit.

I think this problem is less acknowledged than it should be. Likely because sed is implied to be the a smart one-liner tool. One substitution and we’re done. Easy to iterate on, but gets increasingly hard as commands/substitutions accumulate. And no one stays with sed (and ed as an “obvious” “equivalent” of sed) after things get complicated. Most just switch to awk or something.

A shame—ed might have worked well enough and would certainly be easier to iterate on.

Multiline: Because Most Inputs Are

Many of my scripts are working with multiline input. A pattern that I keep using is:

Join lines.
Operate on these lines with “multiline” regex.
And split the lines back out.

# Join lines with semicolons (there are none left)
# Also add one semicolon to the front (useful in wrapping forms below)
g/$/s//;/
,j
s/^/;/

Because this feature is not portable. I know this is premature, but I want my scripts to be runnable in most ed versions out there. Including BSD ed, Mac ed, and... they work in ex too! This portability point especially applies to scripts on RosettaCode—too many eyes on them to fail.

Reproducing this “multiline” behavior in sed means using the forbidden magic: repeatedly reading new lines and (inevitably) using multiline regex. Much harder to understand and only covered by the “Advanced” section of the manual, in passing. Compared to basic commands ed has for these: and .

Stateful and Chaotic: All Over the Place

The fact that ed works with files and buffers allows for some flexibility. One can overwrite files, re-read them, run shell commands, move lines around, and undo anything. Especially so—interactively.

Some of my scripts (like the unreleased Binary Lambda Calculus scripts) are working on files, and overwriting the contents when ready. Because files are a nice way to retain state between script runs. And sed, being a streaming editor, is missing out on state. Yes, you can redirect the output to file or use CD(w) command to append to files. But that’s an afterthought, not a fundamental feature.

So, is ed perfect then?

No. Here are some quality of life features from sed that I miss:

It’s relatively annoying to have to and pipe files into ed, but nothing critical.
y command for transcription: My ed script for Armenian transliteration is 30 lines longer than respective sed one. command is rarely useful, but when it is there’s no ed command for this. I have to substitute every char individually.
looping and branching: Now this one is a killer feature—I can run scripts until the file is ready! I can achieve this with ed by overwriting files in a Bash loop. Or by making ed script call itself recursively. But still. No reasonable ed-native way. Update: ed can be made self-aware and looping with .

As you can see, there are not many features I miss. And it’s nothing compared to ed’s killer features!

Use Ed!

I mean, no, you don’t have to. It’s unlikely that you (like me) are into sticking with obscure tech just because it’s fun. And then discovering that it’s more powerful than expected/mainstream.

But still, the next time you use sed or awk, think: This one-liner could’ve been an ed script. A more stateful yet clear and powerful script.