I googled the author, Patrick J. LoPresti, trying to know more about him and what he is up to. I haven't looked deeply, but I found this easter egg on the game Wasteland 2 [1]:
1992 M.I.T. Class Ring
Description
2 city skylines are etched along the edges of this gold ring.
The face features a busy beaver. The name "Patrick J. LoPresti"
is engraved in script on the interior.
In the kickstarter, $2,000 let you design a personalized item. Wasteland was released in 1988 so somebody who graduated in 1992 may have had fond collegiate memories.
I learned ed, and find it is still useful in many situations. For example, if I want to add a line of text to a file from the command line, I just use ed directly. Another example is trying to change a single line in a file. Even in 2019, ed is still a useful piece of software.
The thing is, if you use vi/vim in your day to day work, you already know ex. Not only that, but most people who will enhance and debug your script will also already know ex (from using it within vi).
I still use ed for a lot of small edits. I also use vi (not vim) a lot: having multiple screens means I can leave an editor open with code for a long time.
It's interesting to see that `ed` is still going strong. I am curious: is anyone on HN using it (semi-)regularly? If so, what are its advantages over other editors (other than maybe the fact that it is probably the smallest editor you can get, unless you do all your editing on the shell)?
I have to admit that I never encountered a situation where `ed` might have been my tool of choice.
I use it when I for some reason need to do something like "delete line 398". Just open ed and do "398d" and "wq". That's my habit for deleting stale entries in ~/.ssh/known_hosts.
For a while I maintained a .html blog using only ed, just for the fun of abstaining from conveniences and learning to use an ancient program. It's somehow nice to know that it's possible.
They recently added ssh-keygen -R to remove entries from the known_hosts file, it's been a big time saver for me. I wish more server providers would tell you the keys your server is using though so you don't have to play the TOFU (Trust-On-First-Use) game.
Interesting, I only learned of it recently, it seems a patch was added to Ubuntu called "mention-ssh-keygen-on-keychange.patch" which puts explicit mention of ssh-keygen -R into the error message, I had assumed it was part of openssh itself and arrived at the same time.
This patch was explicitly rejected in upstream openssh as they said it could lead people to copy and paste it without considering attacks - but ignored the fact that by just telling people what file it was in, many people just deleted the file in response and those who did it right, deleting just the relevant line in cases where a key change was expected like my situation, never discovered the easier ssh-keygen -R method.
Perhaps they shouldn't offer a copy and paste solution, but mentioning that ssh-keygen is capable of it and to see the docs would be nice at least...
This is a common problem with open source projects which don't have huge doc/PR teams — I've seen so many times where someone reinvented something because it was obscurely documented or used a different term than they thought to search for.
I suppose that's not what you meant, but I cannot stop thinking of the poor sysadmin whose files keep getting unexpectedly trimmed to exactly 397 lines.
Also, btw, you can absolutely use ed in scripts [0], but this is also something that I would pity the maintainer of.
You can do the same thing (for me too, ~/.ssh/known_hosts is the most common use case) with GNU Nano: nano +[line number] [filename], then Ctrl-K, then save and quit.
CTRL+K (or CTRL+D to comment out), CTRL+S, quit (current tab: CTRL+W, Alt+Tab or app: CTRL+Q)
Particularly useful when the output of the previous command (compilation for instance) already contains filename:line. Then double click, middle click paste works well.
For about 15 years I developed control systems for the Oil industry. All of my projects had ed built into their OS for cases when I had to telnet into them to do debugging and maintenance for clients. Most of our other projects relied on FTP as the only way to handle "offsite" file editing which often was too difficult to deal with as these devices lived in some of the most remote locations on earth with some of the crappiest network connections.
This seems like one of the times when ed would be a legit editor of choice, rather than the other examples here which seem more like editors of last resort.
ed was built for this kind of system where limited I/O was a requirement for reasonable performance. If transferring a file is too expensive, you can't wait for the system to redraw the entire screen of 25 lines and 80 columns because you scrolled past the bottom of the screen, either.
As an example, one I often used for persuasion during sales, we had to dial into a location, which gave us access to a corporate network. From there it would VPN into an offsite office. From there I would connect with point to point radios 10 miles apart to a Gas rig running on solar panels. The radios had huge SNR numbers because they were near other commercial comm systems, high power power lines and were mounted on masts that would sway in the wind.
To load up a 25x80 area would give me all sorts of bad characters. Doing single lines, and find and replace made it almost feel like I was right next to the hardware.
It was kinda funny when I showed one of the VP's my setup. He had started the company in the 70's using minicomputers. ed was the editor he used to write code. So when I showed him that I was using it on our system he smiled and then questioned how old I was.
I've been using Emacs since 1979. I still don't know vi, and have no desire to learn (I can putter around in it, but it's . . . irritating). For short editing tasks on systems that don't have Emacs (or a sane clone of it) installed, I'll use ed before I'll use vi.
Back in the day, it's amazing how much code one could write in these relatively primitive line-oriented editors (ed on Unix systems, editors like SOS and EDT on DEC operating systems, and so on).
You can comfortably read and comprehend the Unix v6 kernel source code in a day or two. The printed form of Lyons Notes is about half a centimeter thick, maybe 150 pages.
Machines were smaller then, too. 64K of code on a PDP-11, small ROMs (hundreds of KB) for the larger embedded systems.
My belabored point: Systems were smaller. There was a lot less typing involved :-)
There are a bunch more, but nothing that really covers my early experience with Unix. Something about "common tools of the late 1970s line-oriented computing environments" might be an interesting subject, we'll see . . .
Yes I still use it for simple edits (usually removing a line from ssh known_hosts or similar) these days. My fingers learned it at 1200 baud on hacked Xenix machines and it's too late to knock it off.
Similar here: I was trying to troubleshoot a remote system where /usr wouldn't mount, so no termcap, not readline, no lib_anything_helpful_whatsoever.so, nothing. I figured if I were competent with vi then I could at least hack around a bit with ed, and I was right.
In 1991-92 I was doing Unix programming by accessing the host using a terminal emulator on a 80286 PC with MS-DOS. I usually edited my code using vi, but when I compiled and got errors, I would correct minor errors using ed because it didn't erase the error message from the screen. I could quickly go to the line number specified in the error message and make the change. When I got upgraded to an X-Terminal with 19" screen, I changed to running vi or emacs in one window and compiling in another. I have never used ed again except for nostalgic fun. It's like working a puzzle to figure how to make the edits you need with the minimum number of ed commands. I never did use ed on a teletype, but that is where it would really shine.
When they say that ed is the standard editor they really mean it.
A couple of years ago I had to boot a Debian/68k virtual machine and both vi and emacs were absent (there was joe, but at the time I wasn't aware that such editor even existed, and I wouldn't have assumed it came preinstalled anyway).
Well, ed was there.
Quite a challenge to use it because my ed-fu is weak at best, but I was able to edit the necessary files to configure networking and to be able to ssh into the machine.
not sure if there are more than one mg(1), but, since you reference some BSD:
$ uname -s; head -n 19 /usr/src/usr.bin/mg/README
OpenBSD
[This is an edited version of the original mg README, updated slightly to
reflect changes in the last 20 years.]
Mg (mg) is a Public Domain EMACS style editor. It is "broadly"
compatible with GNU Emacs, the latest creation of Richard M.
Stallman, Chief GNUisance and inventor of Emacs. GNU Emacs (and other
portions of GNU as they are released) are essentially free, (there are
handling charges for obtaining it) and so is Mg. You may never have
to learn another editor. (But probably will, at least long enough to
port Mg...) Mg was formerly named MicroGnuEmacs, the name change was
done at the request of Richard Stallman.
Mg is not associated with the GNU project, and it does not have the
copyright restrictions present in GNU Emacs. (However, some modules
do have copyright notices.) The Mg authors individually may or may
not agree with the opinions expressed by Richard Stallman in "The GNU
Manifesto".
Fun fact: MicroEmacs, precursor to mg was written by David G. Conroy while at Mark Williams Company, working on the compiler to run on the DEC Rainbow.
David went on to work on the DEC Alpha, and is now at Apple.
drivers99 mentioned in a comment[0] as reply to another thread that his blind friend used ed to do his coding, using a text-to-speech card that pronounced everything that appeared in the text-mode buffer of the video card. That makes me think of how easy it is to use CLI programs (like ed but not TUIs like vim or emacs) blind. All one needs to do is hookup a text-to-speech program to a terminal output, and that's it.
Yes, I still use it when it comes to scripting, and you have to manipulate files that are nearly gigabytes in size. It is also less battery-consuming, when it comes down to it.
Also, when I teach programming languages, ed is a useful enough project to start on. The editor is simple. So students can focus on language concepts for the most part, while still getting a useful software at the end (I assume regex libraries are available).
`/bin/ed` has gotten me out of a few serious disk recovery binds in the past.
In one of them, a FreeBSD system's `/usr` and `/home` slices got corrupted, but they still had entries in `/etc/fstab`. The mount failures prevented further recovery. There were, however, a handful of binaries under `/bin`. Guess which one is really good at editing `/etc/fstab`...
I'm not a semi-regular user, but a few months ago I wrote an ed script for batch modification of some stuff that, for whatever reason (I don't recall the exact task), was really annoying to do with sed (which I normally go to for that sort of thing).
ed is just one of those things I keep in the back of the toolbox that gets pulled out occasionally.
After reading ‘jecxjo (https://news.ycombinator.com/item?id=18825038) it occurred to me I used ed(1) (or ex(1)??) as part of my response to heartbleed mitigation at $TELCO. A scripted edit across a few thousand machine instances, iirc.
Quick summary of a long story. Working with a guy over the phone to reset a Sun box at a colo cos someone had fixed the ethernet at the wrong speed. He's logging in via serial console and has to edit the conf file. No TERM defined.
Walked him through using ed to change it. He thought it was some arcane magic.
GNU sed has supported sed -i for about 15 years; BSD sed supports it too but you have to write sed -i ''.
The difference is that ed reads the entire input in memory, but it doesn't break symlinks. sed's in-place editing mode (just like perl -i or the newer awk -i inplace that is supported by GNU awk) breaks symlinks, on the other hand it can operate on arbitrarily large files.
By "breaks symlinks", he means that if you run `sed -i` (without `--follow-symlinks`) on a symlink, then it will turn the symlink in to a regular file. GNU sed has `--follow-symlinks` which adjusts this behavior to edit the target of the symlink, and leave the symlink itself alone.
Understanding that ex(1) is not ed(1), I did give myself an “ex(1) challenge” where it was my only editor, whenever available, for 4 weeks. That experiment probably lasted ~6 months, then I drifted back to vi. I’d happily go back to ex(1) though.
I was playing with nixos on a raspberry pi the other day, and something in the install image had made curses programs all confused, so I wrote my configuration.nix using The Standard Text Editor instead of nano.
I tend to use it when I don't want to overwrite the currently printed lines on the terminal and don't want to open a new window. It also helps it doesn't grab the whole terminal screen.
I used it for config update, don't really remember details or why I did not use sed. Also I think I used it once for OpenBSD recovery because that image did not contain any other editors.
Yes... That also caught my eye... I guess it is helpful to have a sensible implementation-neutral standard to prevent implementations from drifting too much. This could be something like the C updates that fix undefined behavior.
> This could be something like the C updates that fix undefined behavior.
Undefined behavior isn't necessarily something that should be fixed, in all cases. In some cases, it explicitly cannot be fixed, as it is undefined explicitly due to known differences in machines.
The whole point of implementation defined behavior is to allow the individual implementations slack. I'm not saying C should be 100% UB free, just that implementation defined is preferable to undefined.
It took over a decade to hit 1.0. But it's simple enough there's never been a whole lot that needs changed. Whole thing is around 3000 lines of code. There was a memory leak that took over 20 years to find and fix though.
I uploaded the whole changelog[1] if anyone wants to read it in a slightly more convenient way than downloading the source tarball.
ed predates the existence of unicode and has made no changes to support it. So it does not "support" unicode but works fine with UTF-8 if your terminal supports it.
As far as ed is concerned some bytes are being pushed around between stdin/stdout/your file, and it does not mangle them so everything works.
Really? ed existed before GNU ed, so at the very start of the project you can basically implement all of the existing features. The "parent" probably doesn't add any new features, and there probably isn't a broad userbase crying about missing bits.
So even with creeping featurism, POSIX_ME_HARDER and other GNU mainstays, I wouldn't think that after the 1.0 release you'd need plenty of new releases.
GNU tar is at 1.3x, and is probably both a bigger bug vector and target for "please add this --long-option-for-edge-case".
Versions were different back then, and programs simpler. People didn't always throw a giant binary over the wall at regular intervals and say "stuff's changed, new major version."
Ah, that page reminded me ("[Edbrowse] was originally written for blind users") of my blind friend from high school who used ed (if connected to unix remotely) or the similar DOS program, EDLIN (to edit locally). This was around 1992. He had a laptop with a fancy add on card and BIOS which would do text to speech of whatever was in the video cards text-mode character buffers. He could have it read character by character if needed. (He wrote most of the C code for a programming competition we were in. He never indented though...)
Hey, great link, thanks. I'd never heard of it before today.
From there I followed a link by the author of edbrowse, Karl Dahlke, called "Command Line Programs for the Blind" [1] which is a great read in general and a really good reminder that accessibility is so important.
https://www.gnu.org/fun/jokes/ed-msg.html