My ed(1) Toolbox

Almost monochrome grayish soft thumbnail. In the middle, “ed(1)” is written by hand. Around it “aed”, “xed”, “oed”, and “wed” are written. There are also “vi”, “ex”, and “sed”, but these are crossed out with deep blood red. Same red outlines the central “ed(1)”. In the corners, attributions to “Artyom Bologov” and “aartaka.me” are barely visible. Someone sure doesn’t like vi...

Apparently, I’m a huge ed(1) fan. I keep posting about it and use it as e.g. my Git editor, sudo editing tool, and my static site generator. But am I using it raw and standard as it is? Sometimes yes, but mostly no. This post is a listing of all the ed implementations and scripts I use.

GNU ed + red—Eternal Classics #

ed(1) is the standard text editor. And it’s available on most UNIX/POSIX-derived systems. (Some Linux distributions don’t provide it in default installation anymore, but that’s on them!) So relying on ed(1) and its powers is a good bet.

That’s why I always have GNU ed installed on my systems. It’s battle-tested, intuitive, and easily scriptable.

Bundled with GNU ed (and any POSIX-compliand ed(1) really), red(1) is the “restricted” version of ed(1). It’s locked to the directory it’s called in. And has no ability to pass through to the shell. I find it relatively useless though: I use ed(1) on secure systems and never allow anyone to access my precious ed(1) session. But still, red(1) is nice to have!

oed—OpenBSD ed #

Now, GNU ed is not conforming to POSIX in some behaviors:

It has more CLI flags
It has wq
It has POSIX extended regular expressions (EREs,) while most other implementations don’t. Thus making EREs a non-portable extension

I risk introducing non-portable behavior if I only focus on GNU ed. And I want to have my scripts (including my website build scripts) portable across implementations.

So I installed OpenBSD ed from the repository kindly provided by one of the maintainers. And now I can safely replace ed with oed for most of my scripts. As the least effort shot at portability. It’s too convenient to not use it now.

wed—ed wImproved #

I asked it on GNU ed mailing list whether they might support scripting abilities. Like sed(1) -e and -f flags or as a special executable for it. One of the maintainers (predictably) replied that they (mostly) abide by POSIX and won’t add it.

But! there was a person that emailed me personally and recommended slewsys ed as a version of ed(1) supporting scripts (among many other things.) So I installed it and called it wed(1) just to distinguish this re-implementation from The ed(1).

I don’t really use wed(1)—I’m fine with standard ed(1) (and my scripting wrapper for it). Bust still, it’s a modern and user-friendly extension. Want to get started with ed(1) but don’t want to deviate from the tradition?—this is the one to start with, probably.

Don’t get wed to an anime hologram. Get wed(1).

aed—Blaphemy Against Minimalism #

I understand the complaints about ed(1) being somewhat hostile to new users. It’s usually mitigated by the time spend with this magnificent software. But still, ed(1) is not perfect and might need some modernization.

So I made aed(1) as a better and more interactive ed(1). It’s mostly abusing Readline and shell scripts to deliver a friendlier experience. With syntax highlighting and perfectly inline-editable inputs.

So once you’re comfortable with basic ed(1). (Or it’s slightly friendlier wed(1) version.) You might want to speed up your workflows with aed(1)!

I might’ve gone too far though.

xed—You Don’t Need sed #

I have a user-friendly ed(1) on me now for interactive use. One use-case for ed(1) is not covered yet though—scripting! Having to do this type of newline-delimited scripts is too verbose compared to sed(1) ones.

dirname=$(printf "a
$1
.
g|/|s|.*/||
p
Qn" | ed -s)

Relatively ugly ed(1) script

What if I told you this is doable with a one-liner using my xed(1) script? Here:

xed "a\n$1\n.\ng|/|s|.*/||\np"

xed script

It’s not the prettiest one, but it’s fulfilling many sed(1) use-cases. Speaking of the devil...

sed and ex... No. #

You don’t need sed(1).

You don’t need ex(1) either, because it’s too vi(1)-oriented. They promised ed(1) eXtended, but we got ed(1) Fucked Up. Commands are incompatible with ed(1). Configuration is useless in ex(1) mode. Overall, ex(1) is just a poorly integrated back-end for vi(1).

My own ed(1) implementations #

If one likes some piece of software as an idea, they will inevitably try to reproduce it. So I did. I implemented ed(1) in Brainfuck under the aegis of Brainfuck Enterprise Solutions. I also did one in BASIC, pushing the limits of the no-memory BASIC as far as possible. And, finally, I did ed(1) in Modal, a term-rewriting-only system. All of these are useable... to a certain extent. But they don’t compare to the magnificence and purity of the Standard Text Editor.

Use ed(1) #

Whatever implementation you pick (pick aed(1)!), use it and love it. Because ed(1) deserves your love 😌