This is the most useful introduction to ed I’ve ever read. That’s not to say I’ve read that many, but most just stop at “ed is a line oriented editor”. This article introduces such niceties as immediate help feedback, a command prompt etc. which I didn’t even know were possible.
I think using ed is a “lost art” as in proficient users don’t really feel the need to spread the word, which means newcomers don’t have anyone to learn from. This post bridges that gap.
(I’m not going to start using ed though, just wanted to appreciate the post).
This is the most useful introduction to ed I’ve ever read. That’s not to say I’ve read that many, but most just stop at “ed is a line oriented editor”. This article introduces such niceties as immediate help feedback, a command prompt etc. which I didn’t even know were possible.
Somewhere in the back of my mind the idea to learn ed and use it for productive work once or twice keeps lingering. Each time I think about it, I realize how much work that would be. It will probably have some vague, unsure benefit, like learning how to think different about editing text, the thing that I do all day, but it would be mostly just for satisfying my curiosity. But there are so many things to be curious about that take less effort, so I never act on it.
And now you bring this up during the holidays. Thanks.
This is actually both delightful and a great guide on how to make ed suck less. A lot of its arcane-ness is just from the fact that the defaults suck quite a lot, now that it’s no longer 1973.
Enable a mode prompt character so you can tell what the heck mode you’re in
Mode prompt would be even better if it included the line number of the current line
Print out help strings on error
Make help strings include more info, like the actual bounds of the file when you tell it to go somewhere out of bounds.
Would this make ed slightly less useful on a 120 baud teletype? Yeah, probably. On a 2400 baud teletype? Nope, not really. Then are some things that are more subjective but rub me the wrong way:
Apparently repeating a q command will quit with unsaved changes. I dislike this ’cause it means the command is context-sensitive but the context is hidden from you.
The line range syntax seems inconsistent. 1,6n prints out lines 1-6, as expected. 1,n prints out line 1, not line 1 to end. But ,6n prints lines 1-6 and and ,n prints out lines 1 to end. Maybe I’m too used to Python’s ranges and the logic to ed’s is different… but Python ranges are really good.
Again for the ranges, if your file is 5 lines long but you do 1,6n it errors ‘cause there is no line 6 to print. I expected it to basically treat the the 6 as “end of file”, but it doesn’t. Surprised me.
…And now I have to talk myself out of making those improvements. “No brain, you may not write an ed replacement. No, it won’t be quick and easy. Stop asking. You have actually useful stuff you should be doing instead.”
This is the most useful introduction to
edI’ve ever read. That’s not to say I’ve read that many, but most just stop at “edis a line oriented editor”. This article introduces such niceties as immediate help feedback, a command prompt etc. which I didn’t even know were possible.I think using
edis a “lost art” as in proficient users don’t really feel the need to spread the word, which means newcomers don’t have anyone to learn from. This post bridges that gap.(I’m not going to start using
edthough, just wanted to appreciate the post).I highly recommend two articles by Brian Kernighan: “A Tutorial Introduction to the UNIX Text Editor” and “Advanced Editing on UNIX.” You can find them both in this PDF copy of the 7th edition of the UNIX Programmer’s Manual.
Also, Michael Lucas has an excellent, slightly longer introduction to ed - called ed Mastery.
Weirdly when I looked for this I just found a giant page that said “EMACS” 😉
Somewhere in the back of my mind the idea to learn
edand use it for productive work once or twice keeps lingering. Each time I think about it, I realize how much work that would be. It will probably have some vague, unsure benefit, like learning how to think different about editing text, the thing that I do all day, but it would be mostly just for satisfying my curiosity. But there are so many things to be curious about that take less effort, so I never act on it.And now you bring this up during the holidays. Thanks.
Working through the examples from this article and trying ed out for a bit, helped me with vim’s search and replace.
This is actually both delightful and a great guide on how to make ed suck less. A lot of its arcane-ness is just from the fact that the defaults suck quite a lot, now that it’s no longer 1973.
Would this make ed slightly less useful on a 120 baud teletype? Yeah, probably. On a 2400 baud teletype? Nope, not really. Then are some things that are more subjective but rub me the wrong way:
qcommand will quit with unsaved changes. I dislike this ’cause it means the command is context-sensitive but the context is hidden from you.1,6nprints out lines 1-6, as expected.1,nprints out line 1, not line 1 to end. But,6nprints lines 1-6 and and,nprints out lines 1 to end. Maybe I’m too used to Python’s ranges and the logic toed’s is different… but Python ranges are really good.1,6nit errors ‘cause there is no line 6 to print. I expected it to basically treat the the 6 as “end of file”, but it doesn’t. Surprised me.…And now I have to talk myself out of making those improvements. “No brain, you may not write an
edreplacement. No, it won’t be quick and easy. Stop asking. You have actually useful stuff you should be doing instead.”For a chaser, try working through A Tutorial for the Sam Command Language (which will work fine with deadpixi’s sam).