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.
https://www.gnu.org/fun/jokes/ed-msg.html