Hacker News Reader

Comment by Topolomancer | Hacker News Reader

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.

View on HN

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.

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.

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?

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

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.

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.

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

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.

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.

`sed -i ...` ?

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.

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.

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

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.

Reply on news.ycombinator.com