s/sed/ed

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 undo 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:

• Add a line marker to (the end of) every line.
• Join lines.
• Operate on these lines with "multiline" regex.
• And split the lines back out.

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: s and j.

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 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:

-f for script files

It's relatively annoying to have to cat 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. y 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 for loop. Or by copy-pasting the commands multiple times in the script file. But still. No ed-native way.

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.

Leave feedback! (via email)