GNU ed 1.15 | Hacker News Reader

GNU ed 1.15

lists.gnu.org

144 pointslelf121 comments

I'm sure most of us have seen this but for those who have not - ed is the standard editor!

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

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.

I wonder if it's a tribute because of his joke.

[1]: https://wasteland.gamepedia.com/1992_M.I.T_Class_Ring

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.

The “WYGIWYG” line is absolutely brilliant.

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.

Why ed over ex?

ed is standard. You can use it anywhere there is UNIX.

ex and vi are also in the POSIX standard. As far as popularity I've actually seen plenty of e.g. busybox based systems that leave ed out but keep vi.

Ed is the standard text editor!

Ex doesn't have much in the way of features that demand an upgrade.[1] Vi is too heavyweight; waiting for the screen refresh is tedious.

[1] Although I recall using it. No idea why. (Mmmmm, 1200bps modem from a C-64.)

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).

Generous enough to flag errors, yet prudent enough not to overwhelm the novice with verbosity.

That was inspired by Subgenius rants (hence the crossposting to alt.slack).

We were pretty into the Church of the Subgenius around that time.

It never gets old. ;-)

Indeed! The whole GNU humor section of the site is all pretty classic stuff.

funny only if you don't know the context..

e.g. it was 'standard' aka invoked by default as $EDITOR as opposed to say ex or teco, etc.

so calling it 'standard' was a good thing here, since it informed you about how the system worked..

Loving it.

I maintain a lightly modified v6 ed[1] for people who want the real deal.

[1]: https://github.com/geocar/ed-v6

According to the page, that version of ed is the editor on which you learned Unix. What editor do you use on Unix these days?

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.

In this case, recently means 2005 when OpenSSH 4.0 was released so you can assume it exists even on things like Red Hat:

https://www.openssh.com/txt/release-4.0

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.

Or just stuff them into the DNS in the form of SSHFP records, where the OpenSSH client will read it from.

This assumes authenticated DNS data, of course. Not at all a given today, sadly.

sed is easier! You can do it with a oneliner:

`sed -i '398d' ~/.ssh/known_hosts`

I do this all the time. In fact I have a function in my .bashrc for this at work since I use it so much:

`function sedkey() { sed -i "${1}d" ~/.ssh/known_hosts }`

so I can run `sedkey 123` etc. Just another way to skin a cat I suppose.

The sed version is more keystrokes. Is ENTER so much more costly?

More keystrokes, but fewer lines of terminal output. Why have 5 lines of output when I don't want any?

  ktm5j@kurma /pool/share/pkgs $ ed ~/.ssh/known_hosts 
  130923
  398d
  wq
  130755

Sed just quietly does what I want. Like I said, just another way to skin a cat, do whatever works for you.

You can use the -s flag to avoid two of those lines of ed output.

You can put the sed version in a cron job

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.

[0] https://www.ibm.com/developerworks/community/blogs/brian/ent...

Interesting. For small things like that I tend to use sed eg sed -e 398d -i .ssh/known_hosts

For larger things I find vi or something else of that scale more convenient. Ed just seems to fill a space between the two that I never need.

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.

Nice! Also applies to kate:

kate filename:line

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.

or: kate filename

CTRL+G line <Enter>, CTRL+K, CTRL+S, quit.

(yet another) one liner:

ed the_file <<< $'398d\nwq'

edit: another one liner but still using ed I guess.

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.

This is by far one of the coolest things I've read regarding remote maintenance. You must also be one of few modern users of `more` over `less`.

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).

> it's amazing how much code one could write in these

E.g. the entire UNIX (including the userland).

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

I would really appreciate reading stories from that time (1979). Have you got a blog with your memories or something?

FWIW, here's one of my more popular posts: http://www.dadhacker.com/blog/?p=987

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.

I once broke a system's libncurses.so and my only access was over ssh due to distance; neither nano, vi, vim, emacs, would work.

ed saved me that day.

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.

wouldn't it have been easier to just edit the files on a local machine?

Possible this predates widespread rollout of SCP and the host didn't have RCP enabled.

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.

I use it to edit known_hosts to delete lines that are offending.

I also use it in some administrative tasks, like editing dhcp.config files on BSD.

None of these happen very often.

If I have a more built-up system, I'll use mg, which is the gnu version of microEmacs.

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".

I believe this is the one.

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.

[0] https://news.ycombinator.com/item?id=18826862

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 use ed when I work in qsh on an IBM system i. The qsh environment acts more like a teletype, so a line editor is my only choice.

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.

While I don't use GNU ed, I do use ed on my OpenBSD laptop as a distraction free editor occasionally.

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.

I use ed in scripts when you need to modify a file in place, something that you can’t do with sed.

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.

> [BSD sed]

you can also do

    sed -i -e 's/a/b/' file

which will work for GNU and BSD sed.

No, it doesn't. On BSD sed it will produce a backup file named file-e. The portable way is to use-i.bak and then get rid of the backup file.

GNU sed has `--follow-symlinks` to have `sed -i` avoid turning symlinks in to regular files.

It would still break hard links though.

If you have hard links your file system is broken.

so... you can't use sed for the same task because it breaks symlinks?

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.

`sed -i ...` ?

sed -i'' ?

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.

I used it plenty when network connection was slow, not anymore unless I need to edit a file from a script and sed & awk ain't cutting it.

Tool of choice? No. Only tool available? A few times, particularly in ramdisk rescue situations.

I do almost all of my editing in "the shell".

Yes! Real programmers use "cat".

Ed is reasonably easy to script, if you hold your mouth just right.

It's going strong enough to justify someone publishing a book on it [1] just last year.

[1] https://www.amazon.com/Ed-Mastery-Standard-Unix-Editor-ebook...

"Ed Mastery will help you:

"....

"•insert, remove, and mangle text"

Yep. That's ed.

Pretty interesting that there are to this day updates in the POSIX standard for ed...

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.

Undefined != implementation defined. The more stuff that gets moved to implementation defined the better.

If everything is implementation defined, why bother with a standard?

https://stackoverflow.com/a/4105123

Why would you want undefined behavior?

To allow implementations slack to do things in the way that works best for them, in some cases of undefined behavior -- but not all of them.

If you have not read it before, you might find "The Value of Undefined Behavior" informative: https://nullprogram.com/blog/2018/07/20/

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's amazing that such a long-lived, ubiquitous program would be only version 1.15.

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.

[1] https://pastebin.com/raw/6XkJCjsU

Does ed support Unicode? That would be one big change that the original designers could not foresee.

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."

I'm more amazed at the opposite: that they're still bringing out new versions. One would have thought ed would be 'finished' by now...

For those who can't get enough ed, there's also edbrowse[0], an the ed-like web browser (and editor, and mail client, ...)

[0]: http://edbrowse.org/

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.

[1] http://www.eklhad.net/philosophy.html

The following article got me interested in ed. It shows how to automate a seemingly difficult to automate operation in an elegant way.

https://jvns.ca/blog/2018/05/11/batch-editing-files-with-ed/

I had the pleasure of trying out ed(1) in its natural habitat last week at CCC, which was very nice https://twitter.com/ProgrammerDude/status/107899350944788070...

Whoever downvoted has obviously never used ed!

Nice.

One thing that I miss and apparently is still not there is the ability to use '*' in place of '1,$' that was in the MWC Coherent version.

Now that the Coherent sources are available[1] under a BSD licence, nothing stops you from compiling your own version of ed!

[1] https://www.autometer.de/unix4fun/coherent/

The source code is on VM images, which run fine under QEMU:

https://www.autometer.de/unix4fun/coherent/ftp/vms/

Off the top of my head, does ‘%’ capture all the lines?

(It does that, or stands-in for the actual filename, or something else :/ )

Ha! Yes it does. Thanks.

Where is GNU TECO (the editor I wrote my PhD thesis with in 1975)? (I'm very curious what my fingers remember 40+ years later.)

It's EMACS now, which started life as a collection of TECO macros.

In 1972, Carl Mikkelson produced the first collection of TECO Editor MACroS.

In 1976, Richard Stallman collected all publicly available TECO Editor MACroS into a single distribution, creating EMACS.

You don't have to run emacs: Teco is alive and well in the BSD ports tree

https://www.freshports.org/editors/teco/

A video showing a guy with nc and bash adding clojure repl support to ed.

https://lambdaisland.com/episodes/ultimate-dev-setup

> * The configure script now accepts appending options to CFLAGS using the syntax 'CFLAGS+=OPTIONS'.

Was this due to an autotools version bump?

Real Python programmers write all their code in ed

This is the best news ever!

Really made my day!

https://www.google.com/maps/@42.2138438,-71.0046955,3a,15y,4...

It's a picture of a street sign saying "WYNOT RD", for those wondering.

Reply on news.ycombinator.com