1) Install rlwrap, which wraps readline around any stdin stream.

2) Save this as something (I call it `rled`)somewhere in your path:

   #!/usr/bin/env bash
   [ !  -n "$(which rlwrap)" ]  && echo "rled: no rlwrap found"  >&2  && exit -1
   rlwrap ed $@

Now you can use ed with readline which allows line navigation, insertion and history.

Ed is the standard text editor.

https://www.gnu.org/fun/jokes/ed-msg.en.html

Hey everyone! I actually use ed almost daily, and at some point I'd like to put up a website devoted to ed oddities. I found in some book that ed was used in the 80's as way to test how fast college students could learn a new technology, under the safe assumption that those students hadn't used ed before. I'm now much more careful when it comes to bookmarking these things, since ed and Google really don't get along, but I lost track of that book or publication. Does anybody know about the study I'm referring to? Any other oddities would be welcome. Thanks in advance.

Cool! I used BSD ed (OS X) exclusively for a few months but I stopped because of a few things that were too clunky for me.

Wrapping text: I used fmt all the time. But you can't pipe text straight through fmt, so I ended up doing this a lot:

3w |fmt>fmt # create a file called fmd in cwd

3r fmt

3d

Which is OK if you have just one line to wrap. If there are newlines in the text you're wrapping, you have to remember the line numbers of the unwrapped text (or use ka, kb) to delete them.

Inserting text in the middle of a line. Either use s// (which is annoying if your inserted text has a lot of slashes) or split the line, add an in between line with the new text, and join.

s/split text/split text\ # <- backslack escapes newline

Then use a or i to insert a line. Then join three lines with j. It gets old after a while.

And then there was my false hope that I learned a universal editor that was everywhere. Except GNU ed is not BSD ed is not OpenBSD ed is not Solaris ed.

Anyhoo, would be fun to read how someone who stuck with it (unlike myself) uses ed.

Thanks for sharing! I should admit I don't do any professional work with text editors (hopefully some day!), and if I ever do ed will likely not be my main editor. Just so you know, you can use most non-blank characters for substitutions. Personally I tend to use commas, as somebody else mention in the comments. If I see commas in the expression I'm about to replace I go for slashes or pipes.

It's interesting you mention inconsistencies across implementations, even more (I assume) going from BSD to GNU ed which unsurprisingly is almost a superset of features with heretical commands such as yank (!).

BSD tends to stick more to POSIX, so issuing just `t` won't duplicate the current line, which I've grown used to. I also like the paging command `z`, which seems to have been adopted by all major implementations. I'm sure Ken would find all of this bloatware!

ed is a god send. Often times, I want to edit a file but don't want to have an editor overwrite the whole screen because I need what was previously printed to edit. When streams aren't enough, ed does the job.

Another psychological thing, it's like exiting a room and forgetting what you were supposed to remember in that room. When an editor takes over the whole screen, I feel a little mental context switch that I have to sort of fight (like having to go back into your memory once you leave a room)while ed seems like less of a break in context since it doesn't wipe the screen. That's my feeling at least.

I agree. Ken Thompson put it like this:

> I don't want to see the state of the file when I'm editing.

In my case at least this is mainly the case for quick edit, though he probably felt this way in general.

A full account by George Coulouris about em, a visual enhancement of ed, is more enlightening:

> By the way, 'em' stands for 'editor for mortals' - I christened it that after Ken Thompson visited our lab at QMC while I was developing it and said something like: "yeah, I've seen editors like that, but I don't feel a need for them, I don't want to see the state of the file when I'm editing".

[1] http://web.archive.org/web/20080103071208/http://www.dcs.qmu...

I'm not sure if you use tmux, but the way I do it is to open a new pane below the original, edit what I need to, and then close that pane when I'm done. The original screen remains untouched.

I once became surprisingly good at using ed because it was the editor available in a MUD environment (LPMud). I think that was in '92.

Shockingly, the MUD (3kingdoms) is still around, though I suspect they've moved on from ed.

likewise, although it rapidly got the boot when I realised there was ftp support and I could just do things locally.

Still found occasional use in tiny little fixes, but never super comfortable using it.

> If you’re using any Unix at all, then ed really will always be there, no matter how old or limited the system.

    kalleboo@Synology:~$ ed
    -sh: ed: command not found
    kalleboo@Synology:~$ vi
    ~       VIM - Vi IMproved

ah

Snark aside, it's a very well-written tutorial! I'm sure I'll end up referring to it at some point in the future.

> Well, unless you’re using Arch Linux.

I would love to know if you're using Arch Linux? There's got to be a good story about why it's not there, if not. Might be fun to hunt down if so (I like historical stories about that sort of decision making).

Going purely off memory here, but I think the discussion on the mailing list went something like:

Why do we include multiple text editors by default?

Good point let’s just pick one for the base install.

Obvious choice is Vi not Ed because more people are familiar with the former.

Aww. That's not terribly interesting at all. I mean, I get it, and I don't doubt it's validity. It's just so... mundane.

I would have thought there'd be utility in having a very small last-resort utility like ed by default. But then I don't use Vi much (or ed, normally I'm just touching up a file from the command line, so I use nano), so perhaps I'm out of touch.

ed has seen use in scripts -- for example, in Kernighan & Pike's The UNIX Programming Environment. `diff` can output an ed script to perform a patch, and that's what people used before `patch` was invented to make patching more robust. I'm surprised you can't rely on ed being present.

I'm working on a codebase right now which uses ed a lot in scripts. I probably wouldn't write new code which used it --- I like awk --- but it actually does the job pretty well.

Admittedly, the code does date back to 1984 in places.

It's the custom GNU+Linux distribution on my NAS (Synology), running an ARM CPU

It's not just Arch. I used to think ed was everywhere, so when I had to write some scripts that would be awful with sed I used ed.

And then it turned out that a lot of the platforms people run the scripts on, they had to install ed explicitly! Ha. Sorry, Arch/Debian/Fedora/Centos/OpenSUSE users.

If you don't believe me, look how many times 'ed' is installed on this page. :) https://gitlab.com/gitlab-org/gitlab-development-kit/blob/ma...

Vim can mostly emulate ed thanks to ex mode. Just symlink /usr/local/bin/ex to your vim binary.

Perhaps your system is something Not Unix?

He is on a synology host, so it's likely FreeBSD. Which is pretty friggin unix

FreeBSD has ed.

I re-wrote ed in C once for fun:

https://github.com/tylerneylon/ed2

It uses the regex and readline libraries, as well as some container data types (array/map) called cstructs. The main C files sum to around 1,000 lines. It was an interesting exercise in learning some of the pieces of building a text editor.

V6 ed (the first in C) was around 1300 lines. http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s... It won't build with a modern compiler, of course.

The code for a simple ed-alike is one of the chapters of Software Tools by Kernighan and Plaugher. For entertainment value, here's a version in Haskell (using Parsec to parse regular expressions (!)): https://www.crsr.net/Programming_Languages/SoftwareTools/ch6...

I'm confused at why the Haskell version is implied to only have entertainment value.

No one is using it, nor has anyone ever done so. I learned about Haskell, but I have rarely used that, either.

> It uses the regex and readline libraries

Given that readline is basically a line-oriented version of emacs (or vi, if you set the config), it sounds like you actually wrote a readline editor with an ed-inspired UI.

ed was the first Unix editor I ever learned, back in 1991. The first terminal I was given in my first job didn't support screen control commands so I could only use line oriented commands such as ed. I got so used to it I still use it occasionally to this day just from habit, though I do now mainly use vi. I occasionally use it in scripts using 'here' documents.

Similar here — the system didn't initially support uncooked input. I don't still use it, but my vim idiolect is still heavy on regular expressions.

ed is perfect in shell scripts:

  % cat <<- _EOF_ | ed -s filename
      ed commands...
  _EOF_

works on all UNIX-like operating systems and it means that temporary files are no longer necessary. (GNU sed -i is an architectural violation of the idea of a stream editor, and it isn't available everywhere.)

Useless use of cat though. You could achieve the same thing by:

  % ed -s filename <<- EOF
      ed commands...
  EOF

I routinely automate text-mangling tasks with short ex (most of them would probably work in ed, too) scripts. I find it simpler than using sed, most of the time. If you're comfortable using ex commands in vim, then it's almost a seamless transition

FreeBSD found out it is not perfect since they had to patch patch because it called ed. People figured out how to run arbitrary scripts in a privileged manner.

patch(1) outputs ed(1) commands. It always worked that way, and it demonstrates the power of the "do one thing and do it well": patch just does the analysis and generates the appropriate editting commands, but the editting is passed on to a program specialized for just that: ed(1). It as also a good showcase for UNIX modularity principle.

It's a good demonstration up until it turns into an attack vector. Then it violates the "do one thing well" part.

It is unclear what this tries to achieve. Could you please explain why this removes the need for temporary files?

If you want to perform an in-place edit, and you want to do it in a portable manner (not using GNU sed -i), you'd have to use sed with at least one temporary file:

  % sed -e 's/something/other/' somefile > /tmp/temp.$$ && mv /tmp/temp.$$ somefile

now, using ed (or AWK) and the heredoc with ed commands above, you can mmap(2) the entire file into memory, perform desired editting, and write it all out in one go. No more temporary files!

Sed, when operating on a file, creates a temporary file alongside the target file.

sed -e s/foo/bar/ | sponge filename

https://joeyh.name/code/moreutils/

You can also use the -i flag of sed to edit a file in-place. It leaves a backup file with the original in case you messed up.

I explicitly wrote:

GNU sed -i is an architectural violation of the idea of a stream editor, and it isn't available everywhere.

precisely to preclude anyone from suggesting using GNU sed -i.

sponge is found on GNU/Linux, but is not a UNIX standard; when writing shell programs one must never assume GNU/Linux, because, as my ed(1) example shows, it is completely unnecessary and makes the code unportable for no reason whatsoever.

Also by relying on external tools, you have now forced your users down the dependency hell path.

Assume the environment you're writing scripts for. Most scripts need only be run on one machine, and thus one platform. Most that don't still run only on one platform. If you need a portable shell script, by all means write one, but that's rarely the case.

Assume you know how to write shell programs which work everywhere without modification; why would you make your program unportable on purpose?

In some cases, it can significantly shorten and clarify the code. That's a Good Thing. Nobody wants to debug shell scripts.

The clean / portable way is in my experience always simpler, or rather, more rudimentary than using unnecessary GNU/Linux-only commands and constructs, simply because the clean / portable methodology uses the lowest common denominator.

If you know of, or have such a case, I would be really interested to see it, out of purely professional interest.

Nobody wants to debug shell scripts.

I want to debug shell scripts, because of all the debugging I've done over the years, shell script debugging is by far the quickest / easiest:

  DEBUG="${DEBUG:-false}"
  $DEBUG && set -x

and one can see the machine state immediately. Best debugging experience by far.

MS-DOS had the similarly frustrating line-at-a-time edlin: https://en.wikipedia.org/wiki/Edlin

Edlin was my first text editor! I used it to write BASIC programs for my parents' 286. Fond memories.

I like ed for simple editing tasks like deleting a range of lines, substituting words, etc.

For a while I maintained an HTML blog only with ed, as an experiment... It really forced me to get used to regexps ranges, thinking before I do stuff, etc...

I've used ed. To write Lisp. Yes, really.

It's by no means my favorite editor (You couldn't convince me to use vi - even the original vi, with its excellent support for Lisp: do you really think I'll drop emacs for ed?), but it's usable, and it works.

Is ed where the slash for regex matching originated or does it go back farther?

Close; it was one of the Bell Labs versions of QED — https://www.bell-labs.com/usr/dmr/www/qed.html — I suspect but am not sure that Ken Thompson's CTSS version, that introduced regular expression text editing, used slash. The original Deutsch/Lampson QED used colons or square brackets for searches (fixed strings, not regular expressions) but did use slashes as the substitution delimiter, which may have inspired Thompson to use the same character for both search and replace.

Does QED source code exist anywhere? A senior developer at SCO gave me a copy of the manual years ago but I've never had an opportunity to try it.

I'm not aware of any.

You can use any character instead of / there. I prefer comma as its easier to type IMO. But slash is too and it's quite distinctive and easy to type too.

Since bash doesn't provide a prepend operator, I define a shell function for that purpose, making use of ed, without need for a temp/intermediate file:

   file_prepend () {
       local ed_cmd="1i"
       if [ ! -f "$2" ]; then
           touch "$2"
           ed_cmd="a"
       fi
       printf '%s\n' H "$ed_cmd" "$1" . w | ed -s "$2"
   }

IIRC the TRS-80 Model III had a similar single-line editor. Once my little fingers knew all the commands, it was pretty efficient.

It's not installed on my Android :(

I love OPs tutorials. If you're reading this, you taught me a lot, thank you.

ed is nice, sam is better: http://man.cat-v.org/plan_9/1/sam

A version of Sam for X with scalable font support no Plan 9 dependencies: http://GitHub.com/deadpixi/sam

The first advice (using "h" or "H") doesn't work on Arch's version of ed. It does work on red, which actually a script that calls sed.

I might actually do that, mostly because I really only do quick edits on the console 99% of the time.

> unless you’re using Arch Linux

pacman -S ed

I think the article was trying to say that you're not absolutely guaranteed to have ed on Arch. Although pulling it in as a dependency is almost unavoidable if you're actually trying to do anything, so you have a fair point.

> Although pulling it in as a dependency is almost unavoidable if you're actually trying to do anything [on Arch Linux]

? The only package on the main repos that pulls in ed as a dependency is `rcs`.

Interesting! I run Arch on a number of machines and your comment prompted me to check my assertion. There are in fact a couple that don't have ed. I think maybe it's often a dependency for more AUR builds? That's the major factor that varies.

My Debian also doesn't have it, though I can't guarantee not having manually uninstalled it (I also uninstalled nano for example).

I think vi is a perfectly sensible choice as the always-there editor.

Why did you/would you uninstall ed or nano? It's not like they're taking up a lot of disk space. I mean, I don't ever use them either, but they're not getting in my way or anything.

> Why did you/would you uninstall ed or nano?

Ed? Maybe because I only ever typo into it, but as I said, I don't think I removed it anyway.

Nano... to be honest, mostly to mess with anyone who'd want to use it. There is no need for it to be on my system, at least not for me, so it's perfectly logical to remove it. But an additional reason is that nano is a terrible editor that nobody should use anyway. Might as well open Geany or something with mouse support if they're not going to take advantage of vi keys (I'm talking about my own laptop with a screen anyway).

I could understand getting rid of nano. For some users, apt-get remove might be the easiest way they can think of for not defaulting to having nano called from other applications, as opposed to finding out about the proper way that Debian would like you to use. Most users would likely know about apt-get long before they ever chance across update-alternatives, (or whatever today's editor-default-selection-method-of-choice is, if it's not that anymore).

I suspect that there are a range of user antipatterns due to either not knowing, or not having the time or inclination to lookup this month's correct method of doing some given task, and people will default to using old methods or silly workarounds.

ed is used somewhat commonly by other programs too, so uninstalling it can break things.

If they do then they should have a package manager dependency, or that's a bug with the distribution.

If you get 100% of your software through the package manager, sure. If not, then manually uninstalling things that have been standard on Unix since version 1 isn't very smart.

ed is posixically mandated, so it's a bug in the distribution anyway.

I never noticed this, and like someone else said, then it should depend on it. I'll notice when something breaks and file a bug I guess :)

Which Debian?

Wheezy/gNewSense 4.0 has it on a default install

gNewSense is not a Debian version unless they gave sid a name, but this is Debian Stretch. If gNewSense (what a terrible name) is a distribution, they might have chosen to install it for you.

Apologies, I should have clarified: gNewSense [1] is a FSF sponsored distro based on Debian with a freed kernel and free packages (basically the equivalent of Debian main). gNewSense is currently at version 4.0 and based on Debian Wheezy.

lucb1e is absolutely right, in Debian wheezy itself, ed is an 'optional' package and not installed by default from the live iso (wheezy 7.11) I just checked. Just one of those choices people make I guess, or, as others have pointed out above, it might well be a dependency of something that I have installed since on my gNewSense install [2].

[1] http://www.gnewsense.org [up and down like a yoyo, mail list archive is much more stable at https://lists.nongnu.org/archive/html/gnewsense-dev/]

[2] http://sohcahtoa.org.uk/pages/gNewSense.html

Right, well, even on debian.org there is no mention of GNU. For what it's worth, to compensate, I've renamed my Cinnamon system menu to "GNU" (so I have a GNU button permanently visible on the left bottom) because they are indeed underrepresented next to Linux. Only in my /etc/issue I can find "Debian GNU/Linux" but it's still a bit of a mouthful, like saying The United States of North America or something when America is clear enough.

I like jed.

To whoever edited the title: I appreciate the addition of the year, forgot to do it when I submitted the story. But I do think the "Actually" is an important part of the title and should be put back in.

As someone who actually uses ed, I sympathize. We've put it back.

Just to avoid a possible misunderstanding, I didn't write this article, I just found it wanting to learn ed. Thanks for putting it back.

An ed for siri would be more intieresting. I feel like siri is eventually just going to be the iphone's version of bash.