s/sed/ed

By Artyom Bologov 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.
u/bigmell in reply to 5 (Wrong) Regex To Parse Parentheses

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

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

# Join lines with semicolons (there are none left)
# Also add one semicolon to the front (useful in wrapping forms below)
g/$/s//;/
,j
s/^/;/
Example of line joining commands
But why join if you can use multiline regex feature? 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: 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)