Why ed(1) is not a good editor today

August 22, 2018

I'll start with my tweet:

Heretical Unix opinion time: ed(1) may be the 'standard Unix editor', but it is not a particularly good editor outside of a limited environment that almost never applies today.

There is a certain portion of Unixdom that really likes ed(1), the 'standard Unix editor'. Having actually used ed for a not insignificant amount of time (although it was the friendlier 'UofT ed' variant), I have some reactions to what I feel is sometimes overzealous praise of it. One of these is what I tweeted.

The fundamental limitation of ed is that it is what I call an indirect manipulation interface, in contrast to the explicit manipulation interfaces of screen editors like vi and graphical editors like sam (which are generally lumped together as 'visual' editors, so called because they actually show you the text you're editing). When you edit text in ed, you have some problems that you don't have in visual editors; you have to maintain in your head the context of what the text looks like (and where you are in it), you have to figure out how to address portions of that text in order to modify them, and finally you have to think about how your edit commands will change the context. Copious use of ed's p command can help with the first problem, but nothing really deals with the other two. In order to use ed, you basically have to simulate parts of ed in your head.

Ed is a great editor in situations where the editor explicitly presenting this context is a very expensive or outright impossible operation. Ed works great on real teletypes, for example, or over extremely slow links where you want to send and receive as little data as possible (and on real teletypes you have some amount of context in the form of an actual printout that you can look back at). Back in the old days of Unix, this described a fairly large number of situations; you had actual teletypes, you had slow dialup links (and later slow, high latency network links), and you had slow and heavily overloaded systems.

However, that's no longer the situation today (at least almost all of the time). Modern systems and links can easily support visual editors that continually show you the context of the text and generally let you more or less directly manipulate it (whether that is through cursoring around it or using a mouse). Such editors are easier and faster to use, and they leave you with more brainpower free to think about things like the program you're writing (which is the important thing).

If you can use a visual editor, ed is not a particularly good editor to use instead; you will probably spend a lot of effort (and some amount of time) on doing by hand something that the visual editor will do for you. If you are very practiced at ed, maybe this partly goes away, but I maintain that you are still working harder than you need to be.

The people who say that ed is a quite powerful editor are correct; ed is quite capable (although sadly limited by only editing a single file). It's just that it's also a pain to use.

(They're also correct that ed is the foundation of many other things in Unix, including sed and vi. But that doesn't mean that the best way to learn or understand those things is to learn and use ed.)

This doesn't make ed a useless, vestigial thing on modern Unix, though. There are uses for ed in non-interactive editing, for example. But on modern Unix, ed is a specialized tool, much like dc. It's worth knowing that ed is there and roughly what it can do, but it's probably not worth learning how to use it before you need it. And you're unlikely to ever be in a situation where it's the best choice for interactive editing (and if you are, something has generally gone wrong).

(But if you enjoy exploring the obscure corners of Unix, sure, go for it. Learn dc too, because it's interesting in its own way and, like ed, it's one of those classical old Unix programs.)


Comments on this page:

and if you are, something has generally gone wrong

That right there seems like the one reasonable argument in favour of taking at least a cursory look at ed even before you actually need it: learning under duress is generally bad in terms of both learning outcomes and surefooted handling of the crisis. It’s good to not be totally unprepared the first time you find yourself dependent on it.

But that certainly doesn’t argue for spending a lot of time mastering it as a daily use editor.

By Stephen at 2018-08-23 00:31:20:

I have been using *nix for some 25 years. I have never once considered using ed. I have probably used sed any time ed would have been remotely useful. Thinking back I can't remember a time when I've needed to edit a file and couldn't use vi.

dc I use all the time. It is an RPN calculator. What's not to love.

I remember only one ocasion where vi(1) was not available. It was some very tiny djbdns/tinydns floppy appliance which had only edit(1) editor because adding vi(1) there - which was possible - took too much space and with other modules it just would not fit in the floppy.

Every other ocasion, no matter which version of Linux or UNIX, even some oldshoold AIX or HP-UX machines, there always was vi(1) available.

I agree with the author of the post, that vi(1) is the standard editor in UNIX land.

Learning ed(1) will be useful in context of for text parsing with sed(1) for example.

... and by the way - on that tiny djbdns/tinydns floppy appliance with edit(1) editor ed(1) was also not available :)

By Greg A. Woods at 2018-10-19 21:01:29:

BTW, editing on printing terminals and over slow and high-latency links was only part of the problem.

Another major issue is that computers back then were slow, very slow by todays standards, and of course they were also very expensive and thus rare.

The implication here is that you wanted to have a lot of people using the same computer, and per-character interrupts were very expensive, especially if they went through to user-land.

Back in university I worked on a VAX 11/780 with 60-odd terminals connected. Even just character echo in the kernel could swamp the CPU if everyone leaned on a repeating space bar at the same time, and thrashing was inevitable if too many people were punching the return key too fast. Even a million instructions per second doesn't go very far with that many users! :-) Worse yet was a PDP-11/60 with only about 16 terminals which we shared with a business class using WATBOL. Some of them learned about the batch job query command and started typing it and running it every few seconds to see how their jobs were progressing through the queue. Luckily there was a window between the terminal room and the computer room and you could see the activity light on the 11/60's front panel and it was relatively easy to show them how expensive it was to run that command so often and how it was slowing all their jobs down (never mind how it made our C compiles grind to a halt).

Meanwhile the local Multics machine which I also used had lots of printing terminals and many more relatively dumb CRTs, over 300 in all, and they were all connected through single-duplex lines (local echo in the terminal) or front-end processors that did the echo for you. The main CPUs could (usually) get on with real computing and thus it had true mainframe performance even with 300 active users. I found out very quickly though how much CPU full-screen editors took when I ran though an entire term's CPU budget (which for that class was already much higher than "normal", $300 vs. $100 if I remember correctly, since we were learning lisp using the interpreter) in less than a week while using Multics Emacs. Luckily my prof was happy to grant me more funny CPU money as he saw I was writing lisp extensions for emacs and learning even more than most of the rest of the class.

Written on 22 August 2018.
« Explicit manipulation versus indirect manipulation UIs
It's time for me to buckle down and add tests to our Django web app »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Wed Aug 22 01:17:53 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.