I've been using it for small edits over the past few months, it's not that bad.

It would take very little to make it very good:

- a quick shortcut to open the file at current line in a pager

- perhaps redesign it to work without having to hit enter after you give a command

The game changer for me was the detailed mode ("H"), which makes ed a lot more pleasant to use. I wish it could be passed on the command line as an option and aliased in the shell... maybe I should patch it.

I've started to find ed surprisingly fun to use for quick edits, I'm not leaving nvi yet but it has this nice "ancient Unix" vibe.

I wanted to use ed for something recently and was punched with:

  bash: ed: command not found

Apparently, despite being mandated by POSIX, not every Linux distro (e.g. Arch) ship it by default

It is very frustrating. In my personal sh library, I probe for `ed` and, if not available, I alias to `ex -s`; I then write in-place editing scripts carefully to use only common functionality to both. Sigh.

Yeah... to my even bigger surprise, ex also was nowhere to be found!

That is very strange; ex should be part of Arch base... oh well, probe for `vi -s` and if this does not work either, get karma on reddit or whatever by making fun of Arch :D

Now that I look at it, base package is missing [0] a bit of stuff:

> The base package does not include all tools from the live installation, so installing other packages may be necessary for a fully functional base system. In particular, consider installing:

> - userspace utilities for the management of file systems that will be used on the system,

> - utilities for accessing RAID or LVM partitions,

> - specific firmware for other devices not included in linux-firmware (e.g. sof-firmware for sound cards),

> - software necessary for networking (e.g. a network manager or DHCP client),

> - a text editor,

> - packages for accessing documentation in man and info pages: man-db, man-pages and texinfo.

[0]: https://wiki.archlinux.org/title/Installation_guide#Install_...

Most Linux distros don't claim to be POSIX compliant. (In fact, software on GNU/Linux in general doesn't claim to be such. Sometimes it's taken as a guideline, more often ignored entirely.)

Which makes GNUs argument for deprecating egrep all the more frustrating.

Found this surprising having used arch for years. Turns out ed is not in GNU coreutils, which is part of the base package. But there's a posix package which includes ed and other posix stuff.

one box I tried recently had the absurd and possibly sacrilegious;

   alias vim='emacs -nw'

   alias vi='vim'

   alias ed='vi'

Mein Gott, some people just want to see the world burn

Debian doesn't seem to install it by default either.

Back in the day, the only in-game editor for MudOS was an ed like editor. I spent many hours on that. It was a factor in deciding to learn vim over emacs at the time.

If I remember well, edlin, the default editor for MS-DOS, was also based on ed.

https://en.wikipedia.org/wiki/Edlin

Per the article the one for MS-DOS was based on CP/M's and the latter's was pretty compatible with ed. But looking at the timelines I'd assume UNIX's ed was based on Multics' qedx, and CP/M's on that or whatever predecessor the Multics one was based on, such as one from CTSS.

If you think ed is confusing or complicated, remember that Ken used ed to build Unix.

And Stallman TECO for ITS.

https://en.wikipedia.org/wiki/TECO_(text_editor)#Example_cod...

I'm showing my age but one of my early compsci courses the only editor available on the lab systems (at least the only editor we had access to) was ed.

After 4 months, I went on a co-op term and vi was VERY nice to use if you had 4 months of intense training in regular expressions and substitution patterns using ed.

At my second job there was a debate between the programmers. ed was too basic. vi was a resource hog and slow.

Given the computing power I have accessible now, it's like looking back on a time when people debated the speed of horses vs. how much oats they ate.

Yeah, my first "real job" we had 5 developers working on a single unix workstation with attached graphics hardware that we time shared.

I carry in my pocket a 4 year old computer with 3 orders of magnitude more ram, storage and processing power.

(2012)

ed's terseness was advantageous and doubly so when working with a thermal printer terminal over an acoustic modem. Source: personal experience.

cheatsheet for the lazies https://catonmat.net/ed-unix-text-editor-cheat-sheet

I thought this was going to be about Ed25519. And I was about to pull out my pitchforks if it ended up talking negative about my boy.

This has piqued my curiosity. What should I read on the subject?

It’s an asymmetric cryptographic signature algorithm that doesn’t suck.

Yes, that much I’m familiar with. I was hoping for some reading that might help me appreciate the finer points, since you seem to think highly of it.

Off-topic: I am pretty sure this comment https://news.ycombinator.com/item?id=34159914 or this comment https://news.ycombinator.com/item?id=34160129 is responsible for this submission, in which case it's not off-topic ^^.

Actually those two: https://news.ycombinator.com/item?id=34161569

ed is not bad at all.

ed is a line editor, which makes it manageable.

This distinguishes it from TECO, which is a character editor.

I find command line character editors hard to use. It's very easy to lose your place, and the cognitive load is just too high for me.

Now, mind, I never used one in anger for any real length of time. But the learning curve was off putting enough to make me seek greener pastures instead.

Like ed.

I used ed for a bit. I was using it to type in the ed clone from the Software Tools book, trying to get it to work in Turbo Pascal on CP/M (with the hope that I could get and ed to work on CP/M, because CP/Ms ed is awful).

It was quite useable and manageable. I had some rough parts, which I can't recall, but it wasn't a horrific experience to be sure.

we once had a little Ed script called "Offending" which would accept the ssh connection failure line

  Offending key ...

and edit the failing key out of the known_hosts file.

extremely useful with bazillions of fresh virtual guests with well known static IP. you simply cut and paste the "Offending key" line into the shell and the ed script does it's magic.

Last time I used ed was to change the network config of a Linux instance in an S/390 LPAR, mostly because I was the only one with any experience with it (an ed clone from back in my CP/M days). Not that I didn't have to scour 1999's Internet for a decent cheat sheet. The mainframe guys were impressed, but I only started breathing when the LPAR came back up and we were able to get a telnet connection.

> 11 Jul 91 - When I log into my Xenix system with my 110 baud teletype, both vi and Emacs are just too damn slow. They print useless messages like, ‘C-h for help’ and ‘“foo” File is read only’. So I use the editor that doesn't waste my VALUABLE time.

This is actually true if you ask ChatGPT to simulate a Unix session, and try editing text files. You literally can't use a visual editor.

Related:

Actually Using Ed (2012) - https://news.ycombinator.com/item?id=30318638 - Feb 2022 (7 comments)

Actually using ed (2012) - https://news.ycombinator.com/item?id=13113556 - Dec 2016 (88 comments)

Actually using Ed - https://news.ycombinator.com/item?id=4120513 - June 2012 (89 comments)

This only focuses on using ed interactively. IMHO, ed's greatest utility is in scripts. For example, I still use "diff -e" as I find for small patches, it is more concise and no less readable. YMMV. I also like ed for non-interactively editing large files.

sed is most preferred, but IME there are some simple tasks that are not possible (or exceedingly difficult) with sed but possible with ed.

For example, moving lines and joining lines are obvious ones. Another is using line address "0", namely, with the "r" command.

Both sed and ed allow reading in a file after line 1 but AFAIK only ed allows inserting before line 1, at "line 0". Acording to the changelog, in 2006, GNU ed was modified so that the "i" and "c" commands treat address 0 as address 1.

For example, a common task for me is to insert the contents of file #1 at the top of file #2, followed by a newline.

AFAIK, this is impossible using sed's "r" command, but it's possible using ed's "r" command.

   test $# -eq 2||exec echo usage: $0 srcfile dstfile
   printf '0r '$1'\nw\nq\n'|ed -s $2 

A less space-efficient solution, without resorting to fifos, might be something like

   cat $2 $1 > $1.$$.tmp;
   exec mv $1.$$.tmp $1;

Turns out this was mentioned on StackOverflow in 2017.

Here is a sed solution

   sed -i -e1r/dev/stdin -e1N $1

However this still has a limitation. The target file must be more than one line.

Using a named pipe for large files

   test -s 1.fifo||mkfifo 1.fifo

   cat largefile > 1.fifo &

   printf '0r 1.fifo\nw\nq\n'|ed -s $1

   curl -A "" -4o 1.fifo https://example.com/largefile.gz &

   gzip -dc largefile.gz|tail -100|sed -i -e 1r/dev/stdin -e1N $1

Instead of sed -i, one can use ired.

   od -tx1 -An|sed 's/^/w /'|ired -n $1 /dev/stdin

Unless I am mistaken, ired does not use a temp file, unlike sed -i.

Still use ed commands but mostly in vi command line mode.

For me the most useful feature is the ability it has to remember the contents of regular expression matches inside \( ... \) and when you combine this with the g global edit command you can do complex manipulations in a similar way on every line in a file with a single ed line.

So

g/\(regex1\)whatever\(regex2\)/s//\2something\1/

switches whatever text matches regex1 and whatever matches regex2 and changes the intermediate text also. It's a lot to type but quite easy once you have done it a few times to write a single edit that transforms your file exactly the way you want in one go or nearly so.

However dealing with columnar data it's probably better to use something like awk.