{"id":11924,"date":"2025-09-30T03:00:00","date_gmt":"2025-09-30T07:00:00","guid":{"rendered":"https:\/\/www.both.org\/?p=11924"},"modified":"2025-09-21T15:00:50","modified_gmt":"2025-09-21T19:00:50","slug":"7-ways-i-use-ed-every-day","status":"publish","type":"post","link":"https:\/\/www.both.org\/?p=11924","title":{"rendered":"7 ways I use ed every day"},"content":{"rendered":"
\r\n
\r\n \r\n <\/i>\r\n <\/a>\r\n <\/span>\r\n<\/div><\/div>\n

We all have a favorite editor that we like to use. Some folks like Visual Studio Code or the open source version VSCodium because it’s a powerful editor packed with features. Others like the classic GNU Emacs because of the LISP-like extension language that makes it more flexible. And others prefer Vim because it’s light and runs everywhere, but doesn’t miss out on features. Or you could find a dozen other editors that people like to use.<\/p>\n\n\n\n

And I like many of these editors. I don’t know how many editors I’ve used in my career, but it’s a lot. Every editor or IDE has a great use case, and I don’t stick to just one. I like Mousepad on Xfce to keep notes, Vim for editing small files, Geany for editing source code, Fed for writing programs on FreeDOS, and so on.<\/p>\n\n\n\n

But there’s one editor I use every day that may surprise you: ed<\/strong>. The original<\/em> Unix text editor, ed<\/strong> is actually a line editor<\/em>, which means it operates on a line at a time. There’s no interface, everything runs on the terminal, without even a prompt. And yet I use it every day. Here are 7 ways that I find myself using ed<\/strong> every day to work with text files.<\/p>\n\n\n\n

1. Editing files on the server<\/h2>\n\n\n\n

I manage several websites, and my hosting service provides a “shell” interface where I can connect via SSH to work directly on my files. This used to be a very responsive way to edit web pages or other files on the web server. Although I’ve noticed since AI bot activity has picked up, the web server has to work harder to respond to traffic across all of the websites hosted there. I don’t think I’ve seen the load average below 20 in the last six months.<\/p>\n\n\n\n

The website is responsive, but obviously my interactive SSH sessions are not. Editing files using Vim just isn’t a pleasant experience when things are that slow.<\/p>\n\n\n\n

Instead, if I only need to make a few quick edits, such as changing a color in a stylesheet file, I find it’s faster to just do it in ed<\/strong>. For example, if I decided that the “gold” color was too strong to use as a background color for highlighted text, I might use this ed<\/strong> session to change it to a lighter color. For this example, I might only have the one instance of “gold” in my stylesheet:<\/p>\n\n\n\n

$ ed styles.css\n2959\n\/gold\n    background-color: gold;\ns\/gold\/lightyellow\/p\n    background-color: lightyellow;\nw\n2966\nq<\/code><\/pre>\n\n\n\n
2. Automating a process<\/h2>\n\n\n\n
I like using the command line, but I don’t like typing the same thing<\/em> all of the time. If I know I’m going to do the same process a second or third time, I’ll usually find a way to automate it.<\/p>\n\n\n\n
In one recent example, I needed to convert a bunch of Markdown files into PDF. The pandoc<\/strong> command will do that for me automatically, except that pandoc<\/strong> uses LaTeX to convert to PDF, and that was overkill for what I needed to do. Instead, I found it was faster to convert Markdown into some intermediate file format, like LibreOffice ODT or Word DOCX, and then use LibreOffice from the command line to process the file into PDF.<\/p>\n\n\n\n
After a few experiments to make sure I had the right commands, I just needed to copy my commands into a Bash script. By using the ed<\/strong> editor, I could still see my previous commands in my shell window, which made it easy to create a script based on those commands.<\/p>\n\n\n\n
$ ed mk-pdf.bash\nmk-pdf.bash: No such file or directory\na\n#!\/bin\/bash\npandoc --from markdown --to docx \"$1\" -o sample.docx\nlibreoffice --convert-to pdf sample.docx\n.\nw\n106\nq\n\n$ bash mk-pdf.bash editor.md\nconvert sample.docx as a Writer document -> sample.pdf using filter : writer_pdf_Export<\/code><\/pre>\n\n\n\n
And when I ran the script, I realized the script should print a brief line when it is running pandoc<\/strong>, so I would know that was the step it was processing. So I made a quick edit with ed<\/strong> once again:<\/p>\n\n\n\n
$ ed mk-pdf.bash\n106\n\/pandoc\npandoc --from markdown --to docx \"$1\" -o sample.docx\ni\necho 'converting with pandoc ..'\n.\nw\n139\nq\n\n$ bash mk-pdf.bash editor.md\nconverting with pandoc ..\nconvert sample.docx as a Writer document -> sample.pdf using filter : writer_pdf_Export\nOverwriting: sample.pdf<\/code><\/pre>\n\n\n\n
3. Writing a Makefile<\/h2>\n\n\n\n
Similar to automating a process with a Bash script is creating a Makefile to automate a build process. If I’m working on a large project with many source files, I’ll probably use an IDE like Geany to edit everything. But if it’s just a short program to do a specific thing, I might write that in Vim.<\/p>\n\n\n\n
After I build the program and know it’s working, I usually create a Makefile to simplify the build process. If you haven’t used make<\/strong> before, you can use a Makefile to control how a project gets compiled, and what files are required to build the project. You can also add other steps to clean up after yourself, or to run a few tests.<\/p>\n\n\n\n
And using ed<\/strong> is a great way to write a quick Makefile. Let’s say I just wrote a quick one-off program to do the Rot-13 “encryption” algorithm. Every time I build the program, I want to be sure to add the -Wall<\/code> option with the C compiler, to report all warnings. I might also want to test the program to be sure it works correctly, so I’ll want to create a test<\/code> target in the Makefile too. And finally, I’ll want to add a clean<\/code> target to remove any temporary files.<\/p>\n\n\n\n
That’s easy with a Makefile. It’s also trivial to write with ed<\/strong>:<\/p>\n\n\n\n
$ ed Makefile\nMakefile: No such file or directory\na\nCC=\/usr\/bin\/gcc\nCFLAGS=-Wall\nLDFLAGS=\n\nRM=\/bin\/rm -f\n\n.PHONY: all test clean\n\nall: rot13\n\nrot13: rot13.c\n        $(CC) $(CFLAGS) -o rot13 rot13.c $(LDFLAGS)\n\ntest: rot13\n        .\/rot13 < t\n        .\/rot13 < t | .\/rot13\n\nclean:\n        $(RM) *~ rot13\n.\nw\n223\nq<\/code><\/pre>\n\n\n\n
And with this Makefile, I can easily compile and test my program the same way every time<\/em> without typing a bunch of commands:<\/p>\n\n\n\n
$ make clean\n\/bin\/rm -f *~ rot13\n\n$ make test\n\/usr\/bin\/gcc -Wall -o rot13 rot13.c\n.\/rot13 < t\nGur Ebg-13 \"rapelcgvba\" nytbevguz whfg ebgngrf\ngrkg ol 13 cbfvgvbaf. Sbe na nycunorg jvgu 26\nyrggref, gung znxrf vg rnfl gb \"qrpelcg\" gur\nzrffntr ol ehaavat Ebg-13 n frpbaq gvzr.\n.\/rot13 < t | .\/rot13\nThe Rot-13 \"encryption\" algorithm just rotates\ntext by 13 positions. For an alphabet with 26\nletters, that makes it easy to \"decrypt\" the\nmessage by running Rot-13 a second time.<\/code><\/pre>\n\n\n\n
4. Writing a test file<\/h2>\n\n\n\n
When I work on a project, I’ll go through several iterations to add some new feature, then test it to make sure everything works the way I want it to. I’ll often test it with files that I know work<\/em> and other files that I think might not work<\/em> to try to break it, so I can learn to catch those conditions before they cause a problem in the program.<\/p>\n\n\n\n
You don’t need to run an instance of a big editor just to create a test file that’s a few lines long. Instead, I find it’s much faster to start a new file in ed<\/strong> and create my test file there.<\/p>\n\n\n\n
$ ed t\nt: No such file or directory\na\nThis is a test file.\n        This line starts with spaces.\nTHIS LINE CONTAINS ALL UPPERCASE.\n.\nw\n85\nq<\/code><\/pre>\n\n\n\n
5. Writing a demo program<\/h2>\n\n\n\n
I’ll use an IDE to work on large projects, or a programmer’s editor to work on big but not too-large projects, and Vim for small things. But for those cases where I just need to write a program that’s a few lines long, I’ll use ed<\/strong>.<\/p>\n\n\n\n
A few weeks ago, I was working on an article to explain some features of the classic FORTRAN 77 programming language. I don’t know that FORTRAN 77 is used much anymore, but it was the programming language we used during my physics undergraduate days to write data analysis or numerical simulation programs, so it’s something that’s stuck with me.<\/p>\n\n\n\n
And because what’s old is new again, retro programming<\/em> means that people want to read about FORTRAN 77. So that’s why I found myself needing to write a few short programs in FORTRAN 77 to explain how a DO<\/code> loop worked, or how the ASSIGN<\/code> statement could be used with GOTO<\/code> to create a primitive kind of subroutine. These are not big programs. I found it was easier to just type out a few lines in ed<\/strong>, compile it, and run it\u2014all from the command line.<\/p>\n\n\n\n
$ ed do.f\ndo.f: No such file or directory\na\n      PROGRAM LOOP\n      DO 10 I=1,10,1\n10    PRINT *, I\n      END\n.\nw\n67\nq\n\n$ f77 -o do do.f\n\n$ .\/do\n           1\n           2\n           3\n           4\n           5\n           6\n           7\n           8\n           9\n          10<\/code><\/pre>\n\n\n\n
6. Fixing typos<\/h2>\n\n\n\n
I write the first draft of most of my articles in Markdown, because it lets me focus on the content<\/em> of what I need to say without getting distracted by the formatting<\/em> to make it look nice. And part of that focus is not worrying too much about typos. If there’s a red squiggle, I’ll ignore it as I’m writing and fix it later.<\/p>\n\n\n\n
Since I’m writing in Markdown, which is just plain text with some minimal markup for basic formatting, I use a command line tool called typo<\/strong> to identify misspelled words. This is actually a script that I wrote several years ago, and it mimics a similar command from the original Unix. The script outputs a list of possibly misspelled words, and it’s up to me to edit the file to fix the errors.<\/p>\n\n\n\n
If I use Vim or some other full-screen terminal-mode editor to edit the file, I won’t be able to see the output from typo<\/strong> anymore. So no matter what editor I might have used to write the original document, I usually turn to ed<\/strong> to fix the typos.<\/p>\n\n\n\n
Here’s a sample session where I ran typo<\/strong> to find possibly misspelled words in an early draft of this article. Most of the words that typo<\/strong> listed were not actually misspelled, except the word eidtor<\/strong>, which I needed to fix manually in ed<\/strong>:<\/p>\n\n\n\n
$ typo editor.md\ndocx\neidtor\ngeany\nmousepad\nssh\nstylesheet\nvscodium\nxfce\n\n$ ed editor.md\n8571\n\/eidtor\n| `q`     | Quit the eidtor. If **ed** prints a question mark, that may mean you haven't saved the file. |\ns\/eidtor\/editor\/p\n| `q`     | Quit the editor. If **ed** prints a question mark, that may mean you haven't saved the file. |\nw\n8571\nq<\/code><\/pre>\n\n\n\n
7. Just for fun<\/h2>\n\n\n\n
In days long ago, technical writers used tools like nroff<\/strong> to create documents including reports, letters, and memos. I first used nroff<\/strong> when I was an undergraduate student; it was a great way to work on class papers from anywhere<\/em> on campus, just by logging into one of the VT220 terminals available in most of the academic buildings at the time.<\/p>\n\n\n\n
And sometimes, I like to write documents with nroff<\/strong> just for fun. Yes, even in 2025.<\/p>\n\n\n\n
When I’m writing just for me, I don’t need a big editor, and I don’t need conditional formatting to highlight keywords. The ed<\/strong> editor will do the job just fine. So I’ll often write a sample document, formatted for the -ms<\/strong> macros, using ed<\/strong>.<\/p>\n\n\n\n
$ ed doc.ms\ndoc.ms: No such file or directory\na\n.TL\nDocument Title\n.AU\nJim Hall\n.AI\nAuthor's Institution\n.AB\nThis is an abstract. Use this to provide a brief summary of the\ndocument and highlight important points. Many of my undergraduate\nlab reports required an abstract.\n.AE\n.NH 1\nIntroduction\n.PP\nHere's a sample document written in nroff.\nI used to write class papers in nroff when I was an undergraduate,\nbecause I could connect to the Unix systems from anywhere on campus\nthat had a VT220 terminal. And I could print my documents just as\neasily using the dot matrix printer in the computer lab.\n.\nw\n553\nq<\/code><\/pre>\n\n\n\n
Try it for yourself<\/h2>\n\n\n\n
The ed<\/strong> editor may be a simple line editor, but it still does the job of editing text. As a line editor, ed<\/strong> operates one line at a time, using commands to enter edit mode<\/em> and manipulate files.<\/p>\n\n\n\n
If you want to get started writing with ed<\/strong>, here are a few key commands to know:<\/p>\n\n\n\n
Command<\/th>What it does<\/th><\/tr><\/thead>
a<\/code><\/td>Append new text starting after the current line. This is also how you start writing in a new file.<\/td><\/tr>
i<\/code><\/td>Insert new text before<\/em> the current line.<\/td><\/tr>
c<\/code><\/td>Change (replace) the current line.<\/td><\/tr>
.<\/code><\/td>Type .<\/code> on a line by itself to stop entering lines.<\/td><\/tr>
\/text<\/code> or ?text<\/code><\/td>Search forwards (or backwards) for text, using regular expressions. This also sets the new current line<\/em> to use with the a<\/code> or i<\/code> or c<\/code> commands.<\/td><\/tr>
s\/old\/new\/<\/code><\/td>Replace text, from old<\/em> to new<\/em>. You can change every line* by using %<\/code> at the start.<\/td><\/tr>
w<\/code><\/td>Write the file (save it).<\/td><\/tr>
q<\/code><\/td>Quit the editor. If ed<\/strong> prints a question mark, that may mean you haven’t saved the file.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
This article is adapted from How I use the ed editor<\/a> by Jim Hall, and is republished with the author’s permission.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"
Here are 7 ways I like to use the ed editor for daily tasks.<\/p>\n","protected":false},"author":33,"featured_media":3293,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_lmt_disableupdate":"","_lmt_disable":"","footnotes":""},"categories":[100,106,5,218],"tags":[104,91,221],"class_list":["post-11924","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-command-line","category-history","category-linux","category-text-editors","tag-command-line","tag-linux","tag-text-editors"],"modified_by":"David Both","_links":{"self":[{"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts\/11924","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/users\/33"}],"replies":[{"embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=11924"}],"version-history":[{"count":2,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts\/11924\/revisions"}],"predecessor-version":[{"id":11926,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts\/11924\/revisions\/11926"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/media\/3293"}],"wp:attachment":[{"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=11924"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=11924"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=11924"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}