Perhaps it's better to see for a minute how people used this kind of editors when they first appeared, than to keep reading about them for ages: https://youtu.be/b6URa-PTqfA?t=100 (BBC from '79, mentioning how people start working from home with the aid of newfangled microcomputers and network connectivity).
I'm reminded most of all of the fdisk util, where the workflow is pretty much the same: print, modify, print, save. But also I can see where Vi/Vim come from, as I regularly do the same thing as in the vid: %s/something/something else/g and then wq.
That video is marvellous, when you compare it to today's technology and how it's used. The angsty "does it mean we'll all have to learn to type?", the female BASIC programmer working from home on her terminal with printer as a display. Great stuff.
Yeah, I'm kinda getting into these vids from the seventies and eighties.
“Introducing The Amazing Compact Disc, 1982” https://www.youtube.com/watch?v=_Tx6TYnPat8 — “You can pick it up and move around, even shake, and nothing happens”, yeah sure bud.
“Susan Kare explains Macintosh UI ergonomics on the Computer Chronicles, 1984” https://www.youtube.com/watch?v=x_q50tvbQm4 — the control panel is just astounding by modern standards, especially seeing as for me the control panel is a litmus test of an OS interface.
Also one of my favorite music-making tutorials is the three-part, three-hour series ‘Intro to Synthesis’ from sometime in the early 80s: https://www.youtube.com/watch?v=atvtBE6t48M — instead of going through all the terminology in ten minutes and one second, the guy takes his time twiddling knobs and showing what each one does.
Get an iPad, and delete all the app icons, except the couple you use every day, like iMail and Safari. (You can always access them from the Applications folder.)
Turn off all the notifications. Set the desktop background to some non-distracting solid color. Keep your data in folders, don't clutter up the desktop.
Use Pages to write things. Or, maybe just use write.as on the web, and let them handle the fiddly details like backup and web page hosting of your work.
If you have a Linux background and just want something simple (but very capable when you need it), run i3 or Sway on Alpine.
Be sure to continue watch also the rest of the video, amazing spot on prediction for amongst other things working from home.
Sort of wish I could work from home distraction free with a typewriter on my kitchen table though, instead having to be constantly be distracted by slack, zoom, email etc.
The printer thing is a teletype. Think of it as a terminal onscreen, but...the text actually gets printed to typewriter paper line by line. The phone thing is almost certainly an acoustic coupler for a 300-baud modem, hooked to the teletype. You'd dial the modem pool for the server you were trying to connect to, and when you heard the happy modem noises come through the handset, you'd slam it down on the two rubber cups, and your modem/terminal would do the Hayes AT dance, and a point-to-point data connection would be established. 300 baud was good for printing teletypes, as the mechanical printhead can only move so fast....
Yeah, looking more closely, acoustic couplers predated the Hayes modem by at least a decade. I don't know what the standard was for agreeing on a baud rate for earlier ones.
In my high school, we had teletypes akin to these for FORTRAN classes, and actual IBM keypunch machines for COBOL.
Our COBOL programs had to be submitted as a deck of cards wrapped with a rubber band. To ruin someone else's assignment, shuffle their deck and return it to the box.
I find ed to be the perfect program to test a new programming language. It demands good support for strings, regexes and data structures while being reasonably sized to be completed in under a week. I polished my C skills as I was learning it by writing this from scratch[1].
I have written several scripts -- some throwaway, some not -- that use ed. If you know what you need to do to edit a file and need it automated, ed is just super handy. Here is a shell script that deletes all comments from a yaml file, then comments out a particular key:
ed $file << COMMANDS
g/^#.\*$/d
/yaml_key:
s/^/#/
w
q
COMMANDS
Except for when it breaks on FreeBSD or macOS. The most portable utility nowadays for desktop systems is ex, actually (because some Linux distros don’t include ed).
In what way? Ed is interactive so you’d be able to act out your script line by line and check for mistakes, which seems easier to me. If you’re cognizant about the differences between ed and ex, you could even debug with vi.
That's nice. I'd probably user Perl for this, but I happened to stumble upon Perl just in time to make sure I'd never become a shell wizard. Anything more complex than a couple of canned commands and maybe a loop, and I go for Perl.
One thing I do like about ed, though, is that when I run eshell within emacs, I can call ed from there. Since ed doesn't make any assumptions on the capabilities of the terminal it runs on, it works perfectly well in that environment, and being able use another editor from within my editor made me very happy for a couple of minutes. ;-)
For some reason it took me years to understand the need for a line editor. It didn't make any sense in my head. Then one day I saw the famous picture of Bill and Allen as kids in front of a teletype [1] and it finally clicked.
The way it worked was like this: As you keyed in your program, letter by letter, it was printed out on the paper immediately like a typewriter. If you ran the program and there was a problem, you'd just read (or re-read) the printout, find the line with the bug, then use a line editor to fix just that line. You might mark the paper with pencil to keep track of the change. After a while if you needed to see the latest version, you'd just print the whole program out, or just the lines you needed.
This realization finally clued me into what was going on when I was 10yo and programming BASIC on a TRS-80 Color Computer. It was essentially simulating a teletype (which makes sense given BASIC's inception at Dartmouth [2]), where you would type each line individually, then if there was a problem, you would edit the program individual lines at a time. I always thought it was an odd until I understood how actually using a teletype actually worked. Also explains why the command to write letters to the screen is called "PRINT".
Yeah, a lot of people would send their work to the line printer at the end of the day, and then start fresh the next day with a pencil to sketch out what they were going to change. Then using ed is a no-brainer.
I heard that a lot of people preferred fewer files and longer functions for the same reason--it was all there on the fanfold output and could be read at once, rather than working in 80x25 chunks. After that mode of working was replaced by interactive programming at the display terminal, we started to prefer functions that didn't span more than 1-2 screens.
Many BASIC interpreters worked exactly like that. On a TRS-80, for instance, you would type your program and, when you needed to edit a line, you’d use the “edit” command with a line number as the argument and drop into a line editor.
I hate to be that guy, but 'ed' is very unix specific. In the mid-1970's (and apparently as early as the 1960's according to Wikipedia), those of us on TOPS/10, TOPS/20 (and perhaps other DEC systems) were using TECO (which of course became EMACS).
Yeah, also for PDP-8s and PDP-11s, which were very popular at the time.
TECO-like editors are interesting to use:
Unlike line editors (like ex/ed/edlin, etc.), the edit position can be anywhere, not just at line boundaries. But there is no screen, so you really need a good imagination to keep track of this..
Also, they can edit files larger than can fit in the edit buffer, but not in the way this works on modern editors, where the editor manages everything. Instead, the editor makes one pass through the large file, copying it from input to output. You get to make changes along the way, in the part of it that fits in the edit buffer.
TECO has a page concept to help with this: you break your large file into pages separated with form feeds, and there are commands to retrieve the next page from the input file and write the old page to the output file. But I've seen TECO clones without the page concept on early micros.
Vestiges of this page concept remain in emacs to this day..
I was never much of an ed user but I did a lot of stuff in EDLIN on PC DOS 3.1. Ed seems a little more powerful and useful.
With 512K of RAM on a 6MHz 80286, using an editor that fit into one "segment" and loaded quickly from a floppy was nice. The original DOS 1.0 edlin was just over 2K.
Of course, we had printed manuals back then, and you could learn EDLIN with the manual on your lap while you typed commands.
I tried out programming in DOS using tools of the period, and I found edlin surprisingly easy to use; easier to get into than ed. It did have a few quirks. It uses the ASCII SUB character, ^Z, to separate the fields of a substitution command. That does eliminate escaping issues at least.
It is actually way more complex than that. Nowadays it doesn't get explained a lot anymore. Especially with every system coming with some fancy bash or zsh with somewhat sane defaults.
But in the past you may have got just some naked Bourne Shell with no defaults at all.
UNIX Power Tools defined, and largely proved the sole occupant, of a class of technical literature.
It's the single book that more than any had me finally grok Unix. I still have my copy, first edition, two-colour printing (blue for "hyperlinks" to related sections).
Jerry Peek is also an absolute treasure for Unix shell wisdom --- bash in particular though he's highly knowledgeable about others as well.
This enlightens me as to how people can code with ed (and why Ken Thompson famously said 'I don't want to see the state of the file when I'm editing.'). It's basically a REPL for writing code. Same as psql, the commands you use to view the state of the text (database) are different from the commands you use to edit the state of the text (database).
Still sucks though. Even in psql I regularly drop into vim with \e to edit whole queries before sending them out.
That's a neat way to think of it. Coming from the other direction, for emacs users, using the command line is like using the editor since the gnu readline lib offers keyboard navigation like emacs.
Except ^W performs a completely different action. I can't count the number of times after switching from a terminal to Emacs within a couple of seconds, my muscle memory still not updated, I hit ^W only to discover I've just deleted 3/4 of the file.
When I started working on Sun systems back in 1991 the first terminal I used was an old model that didn't support all the cursor controls, so my only option for editing was ed. I worked that way for a year, so for a long time I was more comfortable in ed than vi. Of course on most systems nowadays ed and vi are now different modes of the same editor, as the article notes.
> Ken Thompson has an automobile which he helped design. Unlike most automobiles, it has neither speedometer, nor gas gauge, nor any of the other numerous idiot lights which plague the modern driver. Rather, if the driver makes a mistake, a giant “?” lights up in the center of the dashboard. “The experienced driver,” says Thompson, “will usually know what’s wrong.”
Every link I click on opens up a new frame in the current window. Can't move them around, or focus, or anything. Whatever js rendering it is is either a bizarre design choice, or just plain broken.
I also see this text, and I also don't have an old browser, but apparently older than the one the author uses; surprising that just this site depends on the latest bells and whistles.
My absolute favorite remedy for social media addiction.
Read entries from c2 wiki.
Don't know what to do with yourself for a few minutes DO NOT open Reddit, Facebook, Instagram, TikTok, Twitter ... Whatever.
Read the original, classic group discussion on tech. With Ward Cunningham, Kent Beck, Rob Pike, and many many other luminaries contributing to this endless discussion, you cannot fail to be educated on some level.
So before you read another random article here, on medium or some other place where a "10x" dev just learned something about X ... Just don't, go read c2 wiki.
This, alongside BOFH, is worth its weight in gold in terms of humour. I can also recommend reading the jargon file by ESR to really tap 80ies / 90ies hacker culture.
I use ed for pretty much all editing. Have for a few years after I got tired of trying to debug emacs/org mode :) YMMV of course. :) And so I have learned bash/shell better because of it which I am thankful for.
> Is there some operating environment I'm not aware of?
The answer to this question is always yes. In this case for example: plenty of old control devices in industrial settings are still operating and use this bitrate.
I was perfectly happy using Emacs over a 2400 baud modem, on a fully-functional terminal (VT420 or Telix in DOS). But of course, Emacs' terminal display code is/was so heavily optimized as to be incomprehensible.
sure, using ed as your daily driver code editor in 2022 is probably stupid, but it's still useful enough that any linux distro that excludes it by default irritates me
> oh no i reinstalled the os on my vps and now ssh has it on good authority (said authority is line 68) that someone is doing something nasty
ssh-keygen -R $HOST
IIRC the security warning actually used to suggest this command, but then stopped in order to discourage people from thoughtlessly bypassing it. (I don’t like this pracrice of deliberate unhelpfulness—cf Chrome’s “thisisunsafe” HSTS override—but neither do I like the results of being helpful in such cases. Ugh.)
> also it's a nicely "semantic"/compact/comprehensible way of expressing patches in things like portfiles or nix expressions
As far as I can tell, your ed script sans the wq at the end is a valid sed(1) script, and that is what people usually use for casual patching in packaging situations (although Nix also has substituteInPlace et al).
yeah, unfortunately, despite literally being specified in posix (hell, macos bundles it)
one of these days i will go around pestering distro release engineers to include it; after all, it's less heavyweight than any one of their homespun lightdm greeters
The set of utilities specified in POSIX is, erm, not entirely sensible[1]. Though POSIX is more helpful than most large standards I’ve seen, it still ends up mostly having partial implementations (are there any completely 2008-compliant systems, I wonder?).
LPMUD's online editor comes with a reasonable implementation of ed. It's actually the only way to edit files in the MUD environment (and as a result, how I learned ed).
Discworld is a very customized lpmud, though there are other muds also based on Discworld's core code ("driver"). The default editor on Discworld wasn't ed, but a simpler, less-powerful line editor. ed was available as an option, though, last I checked (last time I logged in was when Pterry died, and then I hadn't logged in for years).
ed is surprisingly usable (and useful, and fun to use), you should try it.
> no reason
This is like saying "There is no reason to use UNIX (now that we have Ubuntu, Gnome, and Wayland)." Personally, I tend to stick with the CLI for as long as it gets me where I need.
It's a handy tool for scripting certain kinds of file editing operations. It's also good for editing files over remote management connections that don't implement a proper terminal interface. As with a lot of the Unix CLI, it may not be something you use frequently (or ever), but it's a godsend when you need it.
patch can export to ed-scripts. So that you can bundle creation and editing into your builds, and installers and all sorts, because you can depend on ed existing.
The humorous part of this is from 1991.
https://www.gnu.org/fun/jokes/ed-msg.html
Perhaps it's better to see for a minute how people used this kind of editors when they first appeared, than to keep reading about them for ages: https://youtu.be/b6URa-PTqfA?t=100 (BBC from '79, mentioning how people start working from home with the aid of newfangled microcomputers and network connectivity).
I'm reminded most of all of the fdisk util, where the workflow is pretty much the same: print, modify, print, save. But also I can see where Vi/Vim come from, as I regularly do the same thing as in the vid: %s/something/something else/g and then wq.
That video is marvellous, when you compare it to today's technology and how it's used. The angsty "does it mean we'll all have to learn to type?", the female BASIC programmer working from home on her terminal with printer as a display. Great stuff.
Yeah, I'm kinda getting into these vids from the seventies and eighties.
“Introducing The Amazing Compact Disc, 1982” https://www.youtube.com/watch?v=_Tx6TYnPat8 — “You can pick it up and move around, even shake, and nothing happens”, yeah sure bud.
“Introduction to Microsoft Excel, 1992” https://www.youtube.com/watch?v=kOO31qFmi9A
“Susan Kare explains Macintosh UI ergonomics on the Computer Chronicles, 1984” https://www.youtube.com/watch?v=x_q50tvbQm4 — the control panel is just astounding by modern standards, especially seeing as for me the control panel is a litmus test of an OS interface.
Also one of my favorite music-making tutorials is the three-part, three-hour series ‘Intro to Synthesis’ from sometime in the early 80s: https://www.youtube.com/watch?v=atvtBE6t48M — instead of going through all the terminology in ten minutes and one second, the guy takes his time twiddling knobs and showing what each one does.
The Macintosh UI one is gorgeous. Such simple systems. I wished our computers, or maybe just our phones, would be so simple and non-distracting still.
They can be, if you set them up correctly.
Get an iPad, and delete all the app icons, except the couple you use every day, like iMail and Safari. (You can always access them from the Applications folder.)
Turn off all the notifications. Set the desktop background to some non-distracting solid color. Keep your data in folders, don't clutter up the desktop.
Use Pages to write things. Or, maybe just use write.as on the web, and let them handle the fiddly details like backup and web page hosting of your work.
If you have a Linux background and just want something simple (but very capable when you need it), run i3 or Sway on Alpine.
https://baldphone.com
Be sure to continue watch also the rest of the video, amazing spot on prediction for amongst other things working from home.
Sort of wish I could work from home distraction free with a typewriter on my kitchen table though, instead having to be constantly be distracted by slack, zoom, email etc.
'79 seems like a much simpler time.
1) Mute phone
2) Turn off desktop notifications
3) Set timer
4) enjoy working in peace
5) timer goes off, check feeds for updates
Repeat Steps 3, 4, 5. for timer length suggestions see: pomodoro
Let me simplify and fix this for you.
1) Mute phone
2) Turn off desktop notifications
4) enjoy working in peace
5) check notifications when you like
7) Live a happier and less stressful life.
6) forget to check notifications in a reasonable amount of time and miss important alerts, possibly negatively impacting your career growth.
7) learn to not care so much :)
Edit:// to be fair I have downtime notifications on priority. Everything else is not time critical
>> career growth
Sorry, I don't buy in the fetishisation of that and being instantly available.
If someone needs to get in touch with me, then they will.
Here's the fun fact: they don't need you. Someone else will seize the opportunities you miss while being unavailable.
Also, we created a scenario where they literally cannot get in touch with you even if they need you.. are you expecting an emergency carrier pigeon?
I am sure anyone who worked with gdb without GUI/"dual" mode is aware of this experience.
https://www.seekpng.com/png/detail/350-3502039_-name-stock-p...
whoa! What did I just see!? Could someone please explain to me how that telephone head set placed next to printer thing contraption works?
The printer thing is a teletype. Think of it as a terminal onscreen, but...the text actually gets printed to typewriter paper line by line. The phone thing is almost certainly an acoustic coupler for a 300-baud modem, hooked to the teletype. You'd dial the modem pool for the server you were trying to connect to, and when you heard the happy modem noises come through the handset, you'd slam it down on the two rubber cups, and your modem/terminal would do the Hayes AT dance, and a point-to-point data connection would be established. 300 baud was good for printing teletypes, as the mechanical printhead can only move so fast....
More like 150 baud. I'm not sure if there was protocol negotiations or just a lot of wait back and forth.
I actually used such a thing to dial a BBS when my Atari 800xl's modem got hit by lightning. Obsolete then, and slow but I got my fix. Fun times...
Yeah, looking more closely, acoustic couplers predated the Hayes modem by at least a decade. I don't know what the standard was for agreeing on a baud rate for earlier ones.
I mean, modems and faxes in effect just whistle into the phone line. At some level of proficiency, you might be able to do that yourself ;)
Afaik phone phreaking used a variety of whistling devices of different complexity: from https://slate.com/human-interest/2013/02/phone-phreaks-the-t...
to https://en.wikipedia.org/wiki/Blue_box
http://www.columbia.edu/cu/computinghistory/couplers.html
In my high school, we had teletypes akin to these for FORTRAN classes, and actual IBM keypunch machines for COBOL.
Our COBOL programs had to be submitted as a deck of cards wrapped with a rubber band. To ruin someone else's assignment, shuffle their deck and return it to the box.
The "printer thing" I believe is like a terminal that renders on paper instead of a CRT. The telephone is like SSH.
> The telephone is like SSH.
SSH with 7-bit ASCII encryption :-)
Marvellous. Always wondered exactly how ed was useful :)
I find ed to be the perfect program to test a new programming language. It demands good support for strings, regexes and data structures while being reasonably sized to be completed in under a week. I polished my C skills as I was learning it by writing this from scratch[1].
[1] Shameless plug, here it is: https://github.com/bojle/edd
This could be an interesting challenge: speedrun up to full ed from just cat/tail/echo/head, shell redirects, and compiler of your choice.
Not a "viitor". Not a "emacsitor". Those aren't even WORDS!!!! ED! ED! ED IS THE STANDARD!!!
Exactly. I assumed this would be a link to the glorious document https://www.gnu.org/fun/jokes/ed-msg.html
I love reading C2, but anything in reference to ed(1) besides "Ed, man! !man ed" is wasting my VALUABLE time. :-)
It's reproduced verbatim lower down in the page.
ed checking in, can confirm.
`The standard unix text editor` has been my Slack bio as long as I can remember for a reason.
See also: Rob Pike's sam editor for Plan 9: http://sam.cat-v.org/
Less commands and a language where "everything is a (huge) string". So its operations are not limited to lines like in ed. A tutorial of the command language: http://doc.cat-v.org/bell_labs/sam_lang_tutorial/sam_tut.pdf
And Pike's introductory paper: http://doc.cat-v.org/plan_9/4th_edition/papers/sam/
All in all, the terseness of the language can be quite addictive. :) http://sam.cat-v.org/cheatsheet/
I have written several scripts -- some throwaway, some not -- that use ed. If you know what you need to do to edit a file and need it automated, ed is just super handy. Here is a shell script that deletes all comments from a yaml file, then comments out a particular key:
In most cases I find `sed -i` to be more convenient than using ed in scripts, but the paradigm is a little different.
I finally had an occasion to write a .sed script a few weeks ago and it was one of the highlights of my career.
Except for when it breaks on FreeBSD or macOS. The most portable utility nowadays for desktop systems is ex, actually (because some Linux distros don’t include ed).
Let me guess:Redhat?
Well, of course, sed is not the stantard...
It is still much more usable than ed. At least, it makes it easier to debug your script.
In what way? Ed is interactive so you’d be able to act out your script line by line and check for mistakes, which seems easier to me. If you’re cognizant about the differences between ed and ex, you could even debug with vi.
Hum... I was thinking on the lines of debugging an entire shell script. Sed has way more output options.
For a single edition script (one shell command), yeah, I'd say there is no large difference.
That's nice. I'd probably user Perl for this, but I happened to stumble upon Perl just in time to make sure I'd never become a shell wizard. Anything more complex than a couple of canned commands and maybe a loop, and I go for Perl.
One thing I do like about ed, though, is that when I run eshell within emacs, I can call ed from there. Since ed doesn't make any assumptions on the capabilities of the terminal it runs on, it works perfectly well in that environment, and being able use another editor from within my editor made me very happy for a couple of minutes. ;-)
`diff -e` and `patch -e` produce and consume `ed` commands
For some reason it took me years to understand the need for a line editor. It didn't make any sense in my head. Then one day I saw the famous picture of Bill and Allen as kids in front of a teletype [1] and it finally clicked.
The way it worked was like this: As you keyed in your program, letter by letter, it was printed out on the paper immediately like a typewriter. If you ran the program and there was a problem, you'd just read (or re-read) the printout, find the line with the bug, then use a line editor to fix just that line. You might mark the paper with pencil to keep track of the change. After a while if you needed to see the latest version, you'd just print the whole program out, or just the lines you needed.
This realization finally clued me into what was going on when I was 10yo and programming BASIC on a TRS-80 Color Computer. It was essentially simulating a teletype (which makes sense given BASIC's inception at Dartmouth [2]), where you would type each line individually, then if there was a problem, you would edit the program individual lines at a time. I always thought it was an odd until I understood how actually using a teletype actually worked. Also explains why the command to write letters to the screen is called "PRINT".
1. https://www.gatesnotes.com/About-Bill-Gates/Early-Days-as-a-...
2. https://youtu.be/WYPNjSoDrqw
Yeah, a lot of people would send their work to the line printer at the end of the day, and then start fresh the next day with a pencil to sketch out what they were going to change. Then using ed is a no-brainer.
I heard that a lot of people preferred fewer files and longer functions for the same reason--it was all there on the fanfold output and could be read at once, rather than working in 80x25 chunks. After that mode of working was replaced by interactive programming at the display terminal, we started to prefer functions that didn't span more than 1-2 screens.
That's also why TTY is the name for abstract devices. Terminals are simulated teletypes.
OMG... I just got sucked into a Wikipedia rabbit hole by looking up TTY. Hours!!!
https://en.m.wikipedia.org/wiki/Teleprinter
Enjoy.
Many BASIC interpreters worked exactly like that. On a TRS-80, for instance, you would type your program and, when you needed to edit a line, you’d use the “edit” command with a line number as the argument and drop into a line editor.
And now autistic nerds keep using it, which is fine, but then insist that everyone else should learn it too, which is stupid.
I hate to be that guy, but 'ed' is very unix specific. In the mid-1970's (and apparently as early as the 1960's according to Wikipedia), those of us on TOPS/10, TOPS/20 (and perhaps other DEC systems) were using TECO (which of course became EMACS).
Yeah, also for PDP-8s and PDP-11s, which were very popular at the time.
TECO-like editors are interesting to use:
Unlike line editors (like ex/ed/edlin, etc.), the edit position can be anywhere, not just at line boundaries. But there is no screen, so you really need a good imagination to keep track of this..
Also, they can edit files larger than can fit in the edit buffer, but not in the way this works on modern editors, where the editor manages everything. Instead, the editor makes one pass through the large file, copying it from input to output. You get to make changes along the way, in the part of it that fits in the edit buffer.
TECO has a page concept to help with this: you break your large file into pages separated with form feeds, and there are commands to retrieve the next page from the input file and write the old page to the output file. But I've seen TECO clones without the page concept on early micros.
Vestiges of this page concept remain in emacs to this day..
Also, several versions of TECO (like TECOC and the Scintilla-based SciTECO) are still in active development. :-)
EDLIN in MS-DOS was very similar to ed.
(Here's a short third-party manual that someone wrote. http://www.sqrt-pi.org/boots/Done-That/Edlin-manual/p11.html )
Early MS was heavily dec-10 based, wasn't it? so it's possible its lineage comes through TECO, via CP/M ED.
ed is a derivative of QED, specifically Ken Thompson's versions for CTSS and Multics that added regular expressions.
¹ https://en.wikipedia.org/wiki/QED_(text_editor)
Have any good resources for these OSs?
Someone used to host a TOPS-20 emulator online, but I can no longer find it.. (these days there should be DEC-20 in the web-browser).
Anyway, here are some links:
http://www.columbia.edu/cu/computinghistory/dec20.html
https://www.livingcomputers.org/Computer-Collection/Online-S...
TOPS-20 was really nice.
http://twenex.org/
I was never much of an ed user but I did a lot of stuff in EDLIN on PC DOS 3.1. Ed seems a little more powerful and useful.
With 512K of RAM on a 6MHz 80286, using an editor that fit into one "segment" and loaded quickly from a floppy was nice. The original DOS 1.0 edlin was just over 2K.
Of course, we had printed manuals back then, and you could learn EDLIN with the manual on your lap while you typed commands.
I tried out programming in DOS using tools of the period, and I found edlin surprisingly easy to use; easier to get into than ed. It did have a few quirks. It uses the ASCII SUB character, ^Z, to separate the fields of a substitution command. That does eliminate escaping issues at least.
I remember using an ed clone with a TRS-80 Color Computer running the OS/9 operating system
https://www.roug.org/soren/6809/os9sysprog.html
Previous to that I used the TECO editor on a PDP-11
https://en.wikipedia.org/wiki/TECO_(text_editor)
People make fun of ed, but the command line is basically ed with the ability to execute.
It is actually way more complex than that. Nowadays it doesn't get explained a lot anymore. Especially with every system coming with some fancy bash or zsh with somewhat sane defaults.
But in the past you may have got just some naked Bourne Shell with no defaults at all.
https://docstore.mik.ua/orelly/unix3/upt/ch30_14.htm explains a bit.
They don't make books like this anymore. ;)
UNIX Power Tools defined, and largely proved the sole occupant, of a class of technical literature.
It's the single book that more than any had me finally grok Unix. I still have my copy, first edition, two-colour printing (blue for "hyperlinks" to related sections).
Jerry Peek is also an absolute treasure for Unix shell wisdom --- bash in particular though he's highly knowledgeable about others as well.
This enlightens me as to how people can code with ed (and why Ken Thompson famously said 'I don't want to see the state of the file when I'm editing.'). It's basically a REPL for writing code. Same as psql, the commands you use to view the state of the text (database) are different from the commands you use to edit the state of the text (database).
Still sucks though. Even in psql I regularly drop into vim with \e to edit whole queries before sending them out.
Just keep it in your head. ed must have been a decent upgrade from punched cards.
As a line editor, it’s pretty much editing a deck of punch cards.
This metaphor, BTW, persists on a lot of mainframe related tasks where, while you see lines on a screen, the computer is reasoning about punch cards.
That's a neat way to think of it. Coming from the other direction, for emacs users, using the command line is like using the editor since the gnu readline lib offers keyboard navigation like emacs.
Except ^W performs a completely different action. I can't count the number of times after switching from a terminal to Emacs within a couple of seconds, my muscle memory still not updated, I hit ^W only to discover I've just deleted 3/4 of the file.
You know, I never put it into words myself, but me too. Here for us and others:
There is a solution to your problem: M-x shell
... which is what makes the command line so clunky and annoying.
I used to know a BSD kernel developer who wrote all his kernel code with ed
I'm still using it almost daily, since 1980, although I suppose today it's an emulation inside vim not the real thing.
Not used for my code IDE or anything, but little config files etc.
We had vi on our '11 in 1980 but I could never get along with it and still can't.
Source if anyone's interested. 1700 loc : https://github.com/v7unix/v7unix/blob/master/v7/usr/src/cmd/...
When I started working on Sun systems back in 1991 the first terminal I used was an old model that didn't support all the cursor controls, so my only option for editing was ed. I worked that way for a year, so for a long time I was more comfortable in ed than vi. Of course on most systems nowadays ed and vi are now different modes of the same editor, as the article notes.
?
> Ken Thompson has an automobile which he helped design. Unlike most automobiles, it has neither speedometer, nor gas gauge, nor any of the other numerous idiot lights which plague the modern driver. Rather, if the driver makes a mistake, a giant “?” lights up in the center of the dashboard. “The experienced driver,” says Thompson, “will usually know what’s wrong.”
-- The Unix Hater's Handbook pp. 57
"Note the consistent user interface and error reportage."
I usually knew what I had done wrong. (Really). :-)
https://web.archive.org/web/20140516191215/http://c2.com/cgi...
I still lament that the C2 wiki switched to JS rendering.
Every link I click on opens up a new frame in the current window. Can't move them around, or focus, or anything. Whatever js rendering it is is either a bizarre design choice, or just plain broken.
Aha, is that the reason why I only see a spinning circle? I remember that I still could access it last year.
It tells me that
I also see this text, and I also don't have an old browser, but apparently older than the one the author uses; surprising that just this site depends on the latest bells and whistles.
Related:
“Ed is the standard text editor.” (1991) - https://news.ycombinator.com/item?id=14406846 - May 2017 (8 comments)
Ed is the standard text editor (1991) - https://news.ycombinator.com/item?id=9936980 - July 2015 (3 comments)
Lots more:
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Ed doubters might find this episode of Lambda Island enlightening (and fun): https://lambdaisland.com/episodes/ultimate-dev-setup
My absolute favorite remedy for social media addiction.
Read entries from c2 wiki.
Don't know what to do with yourself for a few minutes DO NOT open Reddit, Facebook, Instagram, TikTok, Twitter ... Whatever.
Read the original, classic group discussion on tech. With Ward Cunningham, Kent Beck, Rob Pike, and many many other luminaries contributing to this endless discussion, you cannot fail to be educated on some level.
So before you read another random article here, on medium or some other place where a "10x" dev just learned something about X ... Just don't, go read c2 wiki.
This, alongside BOFH, is worth its weight in gold in terms of humour. I can also recommend reading the jargon file by ESR to really tap 80ies / 90ies hacker culture.
I use ed for pretty much all editing. Have for a few years after I got tired of trying to debug emacs/org mode :) YMMV of course. :) And so I have learned bash/shell better because of it which I am thankful for.
The last edit was in 2014? Who's worried about 2400 baud modems and terminals not having cursor positioning capabilities? It's 2022, not 1992!
Is there some operating environment I'm not aware of?
> Is there some operating environment I'm not aware of?
The answer to this question is always yes. In this case for example: plenty of old control devices in industrial settings are still operating and use this bitrate.
This is a WikiWikiWeb article (https://en.wikipedia.org/wiki/WikiWikiWeb), that has been running since 1995 and was frozen in 2014.
I was perfectly happy using Emacs over a 2400 baud modem, on a fully-functional terminal (VT420 or Telix in DOS). But of course, Emacs' terminal display code is/was so heavily optimized as to be incomprehensible.
If you use vi, you already know how to use ex.
I always default to mcedit. I can't shake off being raised in Norton Commander in primary school.
There's no reason to use ed. It's a historical novelty at this point. Move on.
"oh no i reinstalled the os on my vps and now ssh has it on good authority (said authority is line 68) that someone is doing something nasty"
done, didnt fill my terminal with vim or emacs, didnt tab over to my gui editor then back againalso it's a nicely "semantic"/compact/comprehensible way of expressing patches in things like portfiles or nix expressions:
etc etcsure, using ed as your daily driver code editor in 2022 is probably stupid, but it's still useful enough that any linux distro that excludes it by default irritates me
> oh no i reinstalled the os on my vps and now ssh has it on good authority (said authority is line 68) that someone is doing something nasty
IIRC the security warning actually used to suggest this command, but then stopped in order to discourage people from thoughtlessly bypassing it. (I don’t like this pracrice of deliberate unhelpfulness—cf Chrome’s “thisisunsafe” HSTS override—but neither do I like the results of being helpful in such cases. Ugh.)> also it's a nicely "semantic"/compact/comprehensible way of expressing patches in things like portfiles or nix expressions
As far as I can tell, your ed script sans the wq at the end is a valid sed(1) script, and that is what people usually use for casual patching in packaging situations (although Nix also has substituteInPlace et al).
> ed .ssh/config
I think this is my ed use-case as well. I've noticed I need to "apt-get install ed" sometimes. The standard editor is not always standard, it seems.
> The standard editor is not always standard, it seems.
Linux distros don’t follow a standard anymore, as as I can tell. And Linux was never entirely POSIX compliant.
yeah, unfortunately, despite literally being specified in posix (hell, macos bundles it)
one of these days i will go around pestering distro release engineers to include it; after all, it's less heavyweight than any one of their homespun lightdm greeters
The set of utilities specified in POSIX is, erm, not entirely sensible[1]. Though POSIX is more helpful than most large standards I’ve seen, it still ends up mostly having partial implementations (are there any completely 2008-compliant systems, I wonder?).
[1] http://www.landley.net/toybox/roadmap.html#susv4
Why not use sed?
Because it’s not standard.
No, it is. And as other people have pointed out, it ships on more distros.
https://pubs.opengroup.org/onlinepubs/009604499/utilities/se...
It's "ed" which is de facto non-standard.
I always used sed for deleting lines from .ssh/config
sed -i 68d .ssh/config
It was an eye-opening experience for me when I realized sed and ed commands are almost identical
It is the Stream EDitor after all.
IIRC, it is mandated by POSIX/SUS, so even if it ends up not being used ever, to deliberately not include it is ... doesn't feel right.
Now that Visual Studio Code has remote edit, you can do all that in a nice, modern way :)
Remote Edit requires installing a node server to connect to. That would crash my router.
LPMUD's online editor comes with a reasonable implementation of ed. It's actually the only way to edit files in the MUD environment (and as a result, how I learned ed).
Ditto, learned ed and C that way. Tried again recently but quickly switched to editing files remotely.
Wasnt there a way to change your editor in discworld? Maybe they use very customized lpmud
Discworld is a very customized lpmud, though there are other muds also based on Discworld's core code ("driver"). The default editor on Discworld wasn't ed, but a simpler, less-powerful line editor. ed was available as an option, though, last I checked (last time I logged in was when Pterry died, and then I hadn't logged in for years).
ed is surprisingly usable (and useful, and fun to use), you should try it.
> no reason
This is like saying "There is no reason to use UNIX (now that we have Ubuntu, Gnome, and Wayland)." Personally, I tend to stick with the CLI for as long as it gets me where I need.
It's a handy tool for scripting certain kinds of file editing operations. It's also good for editing files over remote management connections that don't implement a proper terminal interface. As with a lot of the Unix CLI, it may not be something you use frequently (or ever), but it's a godsend when you need it.
patch can export to ed-scripts. So that you can bundle creation and editing into your builds, and installers and all sorts, because you can depend on ed existing.
I still use /bin/ed over vi. Seriously.
(And then install Emacs and turn off the screen candy fluff they've added over the last 25-30 years).
What about sed? That thing is still useful and far more commonly used than ed.