Thanks to the TUHS and SIMH projects it is possible to run ancient UNIX systems on modern computers. There are some great guides out there on how to install these systems (such as gunkies.org or squoze.net), and I will not repeat that information here. What I will do in this article is give you a brief overview of the various ancient systems, share some tips on how to use them, and provide pre-installed images that you can quickly download and run with a minimum of hassle.
For example, the system I recommend that you start with is 4.2BSD, just click on the link below and note what machine it runs on, a VAX780. Now install simh with your package manager and run the following commands:
$ tar xzf 42bsd.tar.gz
$ cd 42bsd
$ less README
$ vax780 42bsd.ini
# and in a different window
$ telnet localhost 8888
Each system have their own README files, which give important pointers on how to use them. I will also list some reading suggestions in the following sections, but the greatest guide to UNIX, ancient or otherwise, is The UNIX Programming Environment by Kernighan and Pike. You can log in as either root or guest, without a password, on all of these systems, and most will allow you to connect up to 8 external telnet clients (it can take a minute or two before the client connects). When you shut down the system, remember to shut down from the terminal that runs the virtual machine (the vax780 in this case). The "diskless" telnet clients can just be killed.
To give you another quick example: If you feel oldschool and ready for a challenge, you can download the V7 image and run it like so:
$ tar xzf v7.tar.gz
$ cd v7
$ less README
$ pdp11 v7.ini
# and in a different window
$ telnet localhost 8888
You'll note that V7 runs on a different machine, a PDP11, but otherwise the commands are the same. In V7 you may run into some backspace issues: If you are using xterm hit Ctrl and left click, toggle the Backarrow Key (BS/DEL). Alternatively you can just type Ctrl-Backspace. You will see this issue in most of the systems mentioned here, except for the newest BSD releases (in the off chance that the later BSD versions also give you trouble, try running stty erase '^H' in the old system and see if that helps). This issue, and other topics, like networking and importing tar archives, is discussed further in the Appendix below. But for now: The easiest way to move files to/from these ancient systems is simply to copy paste them: To move a file from your host machine to V7 for instance, run xclip file, then in V7 run ed file, then a (append). Now middle click to paste your text, and when it's done writing, run . (stop input) followed by w (write) and q (quit). To copy text from V7 to the host, just drag and mark the text in V7 and middle click to paste it somewhere on the host, such as a text editor.
But now, lets do a quick run down of the different ancient UNIX systems, with appropriate links. Enjoy :)
For a modern user the old BSD's are definitely the easiest to use, they have BSD software that many will expect, such as vi, more, apropos, head, etc... But more then that, the idiosyncrasies of our modern UNIX boxes are highly influenced by the BSD style, so much so, that it can be a real jolt to see what a non-BSD system looked like in the olden days. Superficially, all of these systems (perhaps except 3BSD) are very much alike. A good starting point would be 4.2BSD or 4.3BSD-Quasijarus. (use the vax, not vax780, executable for Quasijarus!)
| System | Machine | Year |
| 2.11BSD | PDP11 | 1991 |
| 4.3BSD-Reno | VAX780 | 1990 |
| 4.3BSD-Quasijarus | VAX | 1988 (4.3BSD-Tahoe fork) |
| 4.3BSD | VAX780 | 1986 |
| 4.2BSD | VAX780 | 1983 |
| 2.9BSD | PDP11 | 1983 |
| 4.1cBSD | VAX780 | 1983 |
| 4.1BSD | VAX780 | 1981 |
| 4BSD | VAX780 | 1980 |
| 3BSD | VAX780 | 1979 |
The most pivotal of these releases was by far 4.2BSD, it introduced two game changing technologies: The Fast Filesystem (FFS, aka. UFS), which has been the default UNIX filesystem ever since (although ZFS is starting to make it obsolete now), and TCP/IP (ei. ``The Internet''). This release had a massive impact, and it made BSD the dominating force in industry and academia for many years, until AT&T finally played catch up and incorporated most of the BSD enhancements in SVR4 (in 1988).
4.3BSD is an optimization of 4.2. 4.3BSD with later enhancements were eventually backported to the PDP11 in 2.11BSD. At this point work was under way to create 4.4BSD, but that version was never released as a fully functional operating system. The reason being the ugly lawsuit between AT&T and UCB (the partially complete 4.4BSD was used as a base in NetBSD and FreeBSD though). 4.3BSD-Reno is a beta release of 4.4, it is called "Reno" (a gambling city in Nevada) since it was risky to use.
Two of these versions have a surprising relevance down to our modern age: 4.3BSD-Quasijarus is a fork of 4.3BSD-Tahoe (from 1988), that tried to continue the "original" line of BSD operating systems. It became dormant in the early 2000's, although forks still exist. It was popular among hobbyists since it has relatively mature networking capabilities and early versions of popular software, such as perl and Emacs can run on it. 2.11BSD has been maintained to this very day! The reason being twofold, it's about the only network aware and practical system you can put on a PDP11. You would think there wasn't a demand for that, but nuclear power plants are reportedly continuing to use their PDP11 machines until 2050! Additionally, IoT has renewed interest in 2.11BSD since it can run on extremely constrained hardware, and efforts are underway to port it to various architectures.
But let's talk a bit about how it all started: Originally, the Berkeley Software Distribution, was just that: A collection of software, that you installed on top of UNIX from Bell Labs. The first BSD release that was a fully fledged operating system was 3BSD. Beyond the software, you can see some BSD idiosyncrasies already in this very first release, such as columnized ls and the kernel writing messages to /dev/console, but by and large, 3BSD still feels very much like a port of V7.
The release impressed DARPA enough to fund the project, with the goal of developing TCP/IP. That kicked development into high gear, and the next release, 4BSD, really started to look like the BSD system that we all know and love today, despite a few rough edges. 4.1BSD was an optimization of 4BSD. And as we have mentioned, TCP/IP finally arrived in 4.2. But people were so anxious for this highly anticipated release, that a few beta versions were also released, the most important of which, 4.1cBSD, included both FFS and TCP/IP, it was used as a base for the PDP11 backport 2.9BSD, and for V8 (see Research UNIX below).
For a modern user, the early UNIX editions from Bell Labs will be very hard to use. This is partially because they are very old. Many users in fact, still used physical line printers as their terminals when V7 came out. Obviously interactive screen applications, such as vi or more cannot be used with a line printer. But the ideology and idiosyncrasies of the original UNIX will also surprise, plausibly even vex, a modern user. What UNIX has become is quite different from what the original authors intended.
| System | Machine | Year |
| 32/V | VAX780 | 1979 |
| V7 | PDP11 | 1979 |
| V6 | PDP11 | 1975 |
| V5 | PDP11 | 1974 |
| V1 | PDP11 | 1971 |
By far, the most pivotal release of these early UNIX systems is V7. In many ways V7 was the birth of "modern" UNIX: It was the first UNIX system that was predominantly written in C, and the first to introduce the programmable Bourne shell, along with vital applications such as sed, awk and tar. Most users today will probably find V7 surprisingly crude and flaky, but the basic elements of what you expect from a UNIX system are largely present. 32/V is a port of V7 to the VAX780.
V6 and V5 are very much alike. From a modern perspective they are very alien and useless. Although you can write C programs, there are no libraries to speak of, and half the system is written in assembly. You can write some limited DOS-like batch files with the shell, but shell scripting as such, is not possible. You can write documents with ed and troff, but not much else. Importing tar archives requires tedious workarounds, since these systems didn't have tar. It may seem humorous when Kernighan called V6 ``the state of the art in computer operating systems'', but at the time, it was.
Versions prior to V5 were lost, but recently, enough ancient artifacts were discovered, that a working V1/V2 hybrid was restored. Historically this is quite amazing, but do not expect this system to be anything like a usable operating system! This is extremely early days, V1 had neither C nor pipes! It had ed, a PDP11 assembler and a file system, that's about it. In fact, V1 was little more then castrated Multics (a ``Eunuchs'' aka. ``UNIX''). Impressively though multiple users can connect to this system simultaneously, write and mail each other, and otherwise collaborate on common projects. These crude beginnings laid the foundation for the Internet.
Shortly after V7, AT&T commercialized UNIX heavily and created a proprietary edition called UNIX System 3, or SysIII. The next iteration was called System 5, or SysV.* There were four major releases of SysV, which are often abbreviated SVR1... SVR4 (UNIX System 5 Release 4). Generally speaking SysV followed a very orthodox development model, where backward compatibility was a primary goal, but the BSD enhancements were eventually incorporated into SVR4.
During the 80's there were fierce competition, both technically and ideologically, between the two UNIX camps. Sadly, it is very hard to run, or even study, the AT&T UNIX editions today, since they are still protected by ironclad license stupidity. But the two earliest editions have finally been released to the public.
| System | Machine | Year |
| SysVR1 | PDP11 | 1983 |
| SysIII | PDP11 | 1982 |
Generally speaking, both systems are very similar to V7. They are noticeably quicker and smoother, but the applications and overall behavior are largely identical. You only have ed for instance (SysVR1 include vi, but it doesn't work), and ls don't print in columns. Modern users will find these systems quite challenging to use.
Although AT&T took over the reigns and created SysV, the original UNIX design team at Bell Labs were allowed to continue the development of their operating system, referred to as ``Research UNIX'' after V7. These editions were used internally in Bell Labs, but had little exposure beyond that. Eventually this work led to the development of a totally new operating system, Plan 9 from Bell Labs. The idea was to rewrite UNIX from scratch with 20 years of hindsight, and in light of new technological realities, such as networking, graphics and multiprocessing.
| System | Machine | Year |
| V8 | VAX780 | 1985 |
It is possible to run V9 in the Sun-3 TME emulator, by first installing SunOS4, and then V9. But V10 cannot currently be emulated, and likely never will, although you can download and study the source code. V8 on the other hand can easily run on the vax780 emulator provided by SIMH.
V8 is a very pleasant system, in my humble opinion, the best one listed in this article. It imported many of the BSD enhancements, such as vi, more, rouge and of course TCP/IP (albeit with next to no network applications), so you can use it much like a BSD system. But the real beauty of V8 is that it was designed to be used with the graphical Blit terminal. A Blit terminal connected to the VAX780 server could run a simple window manager (mux), a graphical text editor (jim) and a handful of simple desktop games (eg. demo pacman). To use V8 in this way today, you need to install a Blit emulator. A Linux port of it can be found here. Once the vax780 server has booted, you can connect a blit client to it like so:
$ blit -b 19200 -C 000000,00ff00 -t tcp!localhost!8888
PS: If you plan on using V8 with regular text terminals (ei. telnet), you should change the TERM=blit line in your V8 users ~/.profile to TERM=vt100.
There are two main sources of terminal troubles when using an ancient system. The first is that the UNIX system you are using, and your terminal emulator, should ideally have the same TERM configuration, or at least compatible configurations. Usually, it is sufficient to run TERM=vt100; export TERM on the old UNIX machine. I have already added this to the root and guest users ~/.profile (and set setenv TERM vt100 in ~/.login in case you're planning on using the csh shell). Note that you don't have to bother with the TERM setting unless you are using curses applications, such as vi or rogue. In other words, this is only relevant for the BSD systems here.
PS: The exception here is V8, I have configured it to use the Blit term by default. If you plan on using V8 with regular text terminals (eg. telnet), you should change the TERM=blit line in your users ~/.profile to TERM=vt100.
The second tricky problem has to do with the backspace key. Originally UNIX used the BS character (ASCII character 8 (010, 0x08, also represented as ^H)) for the erase function, and the DEL character (ASCII character 127 (0177, 0x7F, also represented as ^?)) for the intr (interrupt) function. This is incompatible with the modern convention introduced in 4.1BSD: That backspace writes a DEL character, and that ^C (ei. Ctrl-C) is used to interrupt (ei. stop) a program.
There is an easy and a hard way around this. The easy approach is just to type Ctrl-Backspace, or even Ctrl-H, and that will (usually) send a ^H character. The hard way around this is to change your system to send ^H whenever the Backspace key is pressed. It's hard because different applications and UNIX systems handle the situation in their own peculiar ways, it's a right mess. Most terminal emulators though will let you set this relatively easily: In xterm for example, hit Ctrl and left click, then select Backarrow Key (BS/DEL). In the Xfce terminal go to Edit -> Preferences... -> Compatibility, and choose Control-H for Backspace and ASCII DEL for Delete key. GNOME and Mate terminals follow a similar procedure, as for KDE terminals you may need to fiddle with System Settings.
In some weird situations, modern programs may actually use the old ^H method, which will throw the late BSD systems here out of whack (9term and cool-retro-term are two such examples). Typing Backspace in those terminals will produce literal "^H" strings in late BSD's, but it's easily fixed: Just type the command stty erase '^H' in these BSD's and things should work fine.
There are a few conflicting instructions out there on the web on how to do this, many of which will not work in practice. The method that has worked for me is the following: Download Wolfgang's fixes for V6, and compile the enblock.c and deblock.c files in this directory:
$ tar xzf v6enb.tar.gz
$ cd v6enb
# you can use clang if you want
$ gcc -o enblock enblock.c
$ gcc -o deblock deblock.c
# and assuming ~/bin is in your PATH:
$ mv enblock deblock ~/bin
With this in place, moving tar files from/to most of these ancient UNIX systems is fairly easy (PS: you need GNU tar here):
# on the host:
$ cd mydir
$ tar --format=v7 -cf files.tar *
$ enblock < files.tar > files.enb
# on BSD UNIX, add this to init file (eg. 42bsd.ini):
att ts0 files.enb
# on AT&T UNIX, add this to init file (eg. v7.ini):
att tm0 files.enb
# on the ancient UNIX system:
$ tar tv0 # list files in archive
$ tar xv0 # extract files to disk
$ tar cv0 * # put disk files on tape
# on the host again:
$ deblock < files.enb > file.tar
$ tar --format=v7 -tf files.tar # list files in archive
$ tar --format=v7 -xf files.tar # extract files
Generally speaking, the older the system, the more trouble you'll run into: These instructions will not work on BSD's prior to 4.2, nor will they work for V8 or 32/V. Systems prior to V7 did not even have tar! You can dd a file easily enough though:
# on the host:
$ enblock < myfile > myfile.enb
# now add this line to v6.ini:
att tm0 myfile.enb
# in V6:
$ dd if=/dev/rmt0 of=myfile
$ dd if=myfile of=/dev/rmt0
# on the host again:
$ deblock < myfile.enb > myfile
V6 did have the tp command, a precursor to tar, and it is possible to move tar files to V6 using V7 as an intermediary, but it's fiddly. For V5 and V1, things are even worse, so I suggest a different method:
Working with tapes and tar files in SIMH can be hairy, and in practise it will not work for many ancient systems. Using bundle from page 98 in The UNIX Programming Environment, is a simple work around:
#!/bin/sh
# bundle: group files into distribution package
# usage: bundle files... > package
# to extract: sh package
# bugs: discard this header on V7; V6/V5 and V1 wont work
for i
do
echo "echo $i 1>&2"
echo "cat >$i <<'End of $i'"
cat $i
echo "End of $i"
done
The idea is to concatenate a bunch of files, interspersed with snippets of shell code, so that the resulting shell script can be executed, and the original files will be extracted. You don't need to copy paste your files one by one into your SIMH client, just make a bundle, xclip it, and then paste it. From the SIMH client you can then extract the files. As long as you only need to copy text files to a single directory, this method works well.
Essentially, you can follow the same strategy when moving files from SIMH to the host, except for an obvious difficulty; you cannot xclip from a SIMH client. You can however run script(1) before starting the SIMH emulator. Your entire session will then be saved in a file called typescript. So print out a bundle in SIMH, shut down the emulator and exit from script, you can then mine out the bundle package from the session log. To demonstrate:
# Transfer from host to SIMH:
# From host
$ ls
ch01.1 ch01.3 ch02.2 ch04.1 ch04.3 ch05.1 ch06.2 ch06.4
ch01.2 ch02.1 ch03.1 ch04.2 ch04.4 ch06.1 ch06.3 ch07.1
$ bundle * | xclip
# From SIMH client
$ ed
$ a
# paste your book by middle clicking
$ .
$ w book
$ q
$ sh book
$ rm book
$ ls
ch01.1 ch01.3 ch02.2 ch04.1 ch04.3 ch05.1 ch06.2 ch06.4
ch01.2 ch02.1 ch03.1 ch04.2 ch04.4 ch06.1 ch06.3 ch07.1
# Transfer from SIMH to host:
# From host
$ script
Script started, output file is typescript
$ pdp11 v7.ini
# From SIMH client
$ ls
ch01.1 ch01.3 ch02.2 ch04.1 ch04.3 ch05.1 ch06.2 ch06.4
ch01.2 ch02.1 ch03.1 ch04.2 ch04.4 ch06.1 ch06.3 ch07.1
$ bundle *
...
$ echo END HERE
# shutdown SIMH client
# From host
$ exit # stop recording with script(1)
$ ed typescript
1,/$ bundle/d
/END HERE/,$d
w ! tr -d '\r' > book # remove carriage returns
q
$ sh book
$ rm book
$ ls
ch01.1 ch01.3 ch02.2 ch04.1 ch04.3 ch05.1 ch06.2 ch06.4
ch01.2 ch02.1 ch03.1 ch04.2 ch04.4 ch06.1 ch06.3 ch07.1
PS: For Plan 9 users; cat book > /dev/snarf, then paste the text in your SIMH window. To copy from SIMH, connect to it with a regular Plan 9 terminal, not vt, print out the bundle and disconnect from SIMH, then cat /dev/text > typescript.
In the above example, we ended the bundle print out by echoing END HERE. That is just a convention to make the subsequent extraction of this block of text easier. You can use a different string if you wish, but make sure it doesn't conflict with the contents of your files (eg. an END statement in an awk script). We also use ed to mine out our book. Again, you can choose a different method (eg. sed -n '/$ bundle/,/END HERE/p' typescript | sed -e 1d -e '$d' | tr -d '\r' > book), but i figured ed deserved a spot in the limelight, especially in the context of this article ;)
Now, the bundle script does have one hard dependency; a Bourne shell. So it cannot be used with the very earliest UNIX systems, ie. V6, V5 and V1. But these systems did have ed, and we can convert a Bourne shell bundle into an ed script easily enough:
#!/bin/sh
# edbundle - convert bundle scripts to ed scripts
# usage: edbundle < package > package.ed
# to extract: ed < package.ed
# bugs: doesn't handle src files including "End of"
awk '
BEGIN { println=0 }
{ if ($0 !~ /End of/ && println) print }
/End of/ {
if (println) {
println=0
print "."
print "w", file
print "1,$d"
} else {
println=1
file=substr($2,2)
print "a"
}
}' /dev/stdin
To demonstrate:
# From host
$ bundle * | edbundle | xclip
# From SIMH
$ ed
# paste your book by middle clicking
$ q
$ ls
ch01.1 ch01.3 ch02.2 ch04.1 ch04.3 ch05.1 ch06.2 ch06.4
ch01.2 ch02.1 ch03.1 ch04.2 ch04.4 ch06.1 ch06.3 ch07.1
Note that you don't need to a append text or w write any files here, since the edbundle output includes all of those instructions. (PS: # and @ signs have special meaning in early UNIX, so copying source code with such characters will cause problems) To export files from SIMH, we need to assemble an ed script (we could just as easily assemble a Bourne shell script, but I find it more mnemonic to use ed scripts in both directions). Here is one suggestion that will work on both V6 and V5:
# From SIMH
% cat edbundle
if ! -r files goto exit
(echo /files/d;\
echo "1,$s/.*/echo a;cat &;echo .;echo w &;echo '1,$d'/";\
echo w) | ed files
sh files
rm files
exit 0
: exit
echo Error: file list is missing!
exit 1
% chmod 755 edbundle
% ls
ch01.1
ch01.2
ch01.3
...
% ls >files
% edbundle
...
% echo END HERE
# From host
ed typescript
1,/% edbundle/d
1,/^a/-1d # remove ed output header
/END HERE/,$d
w ! tr -d '\r' > book # remove carriage returns
q
$ ed < book
$ rm book
$ ls
ch01.1 ch01.3 ch02.2 ch04.1 ch04.3 ch05.1 ch06.2 ch06.4
ch01.2 ch02.1 ch03.1 ch04.2 ch04.4 ch06.1 ch06.3 ch07.1
As you can se, our edbundle Thompson shell script expects to find a file in the working directory called files containing a list of which files it should include in the package. We could adjust our script so that it automatically runs ls >files, but I find it more useful to do so manually, in case I don't want to print all of my files. (but it might be a good idea to add echo END HERE to the end of our script)
For V1 things are more challenging; it does not have basic things like grep or pipes, and a nasty bug even prevents text printed by echo to be used as input by ed. (feel free to debug the pdp11 assembly source code...) But we can at least automate the process somewhat:
@ cat edbundle
echo a >>files.ed
cat $1 >>files.ed
echo . >>files.ed
echo w $1 >>files.ed
echo 1,\$d >>files.ed
@ ls
ch01.1
ch01.2
ch01.3
...
@ sh edbundle ch01.1
@ sh edbundle ch01.2
@ sh edbundle ch01.3
...
@ cat files.ed
...
SIMH will take care of any networking to the ancient system, you can for example telnet into the client from any remote machine, as long as the host server allows such external connections (once multiple users have logged in remotely, they can of course mail and write each other). If you want the client however to talk to the host, you need to create a bridge between SIMH and your host. You'll find some outdated examples in the SIMH docs on how to do this, but there is little reason to do so. Only the newest of these ancient systems, such as 4.2BSD or 4.3BSD, have any network applications to speak of. And only ftp has any practical value, but there are other ways to move files between client and host.
PS: For various reasons, logging in from external telnet clients does not work on all of these systems. Currently, the 43BSD-Reno, 4BSD, SysIII, SysVR1 and V5 images do not allow this.
Most of these systems come with source code included, which you can inspect natively. But it might be more convenient to read the source on your host machine, where you have recursive grep and other useful things. You can get a git repo of ancient UNIX sources, and inspect them like so:
$ git clone https://github.com/dspinellis/unix-history-repo
$ cd unix-history-repo
$ git checkout Research-V5
$ find . -name cat.c
./usr/sys/dmr/cat.c
$ vim usr/sys/dmr/cat.c
$ cloc usr/source
Assuming you are running 9front, it already includes a Blit emulator, and you can install SIMH like so:
; cd /tmp
; 9fs 9front
; tar xzf /n/9front.org/extra/simh.tgz
; cd simh
; plan9/build_all
; mkdir $home/bin/$objtype/simh
; dircp BIN $home/bin/$objtype/simh
You can now download the V8 image for instance (in mothra right click and choose moth mode, then click on the download link), and run it like so:
; tar xzf v8.tar.gz
; cd v8
; vt
; simh/vax780 v8.ini
Once the UNIX system is up and running, right click the vt terminal and choose raw, this will send key sequences like Ctrl-D and Delete to the UNIX system, and not to your Plan 9 system. Once you have halted the UNIX server, right click the terminal again and choose cooked, you can now hit the Delete key to interrupt the process and quit SIMH. To connect a graphical Blit terminal to your V8 server, run (substitute mymachine for the name of your machine):
; games/blit -b 19200 -C 000000,00ff00 -t tcp!mymachine!8888
PS: Plan 9 uses the old UNIX style of ^H for erase and ^? (Delete key) for intr. This works very well for most of the ancient systems here, but not for the newer BSD's. In those you can run the command stty erase '^H', and backspace will work properly. Naturally you want to set TERM=vt100 when using these systems with the vt terminal (also for V8, if you don't plan on using it with Blit).
Except for the BSD's and V8, the UNIX systems provided here only have one text editor, ed. And yes, it is fairly hard to use, but hopefully the following tips will make it a bit easier:
Here is a short, but relatively substantial, demonstration of its use:
$ ed poem
?poem # Warning: file doesn't exist!
a # append text
Great fleas have little fleas
upon their backs to bit 'em
And little fleas have lesser fleas,
and so on ad infinitum.
. # stop input
1,$p # print file (1st to last line)
Great fleas have little fleas
upon their backs to bit 'em
And little fleas have lesser fleas,
and so on ad infinitum.
2s/^/ / # add spaces to beg of line 2
4s/^/ / # same for line 4
1,$p # lets see what it looks like
Great fleas have little fleas
upon their backs to bit 'em
And little fleas have lesser fleas,
and so on ad infinitum.
a # lets add a footer
De Morgan
. # stop input
.= # what line are we on now?
6
t. # duplicate line (ei. 6t7)
s/./-/g # change all chars to "-"
1,$p # lets see what it looks like
Great fleas have little fleas
upon their backs to bit 'em
And little fleas have lesser fleas,
and so on ad infinitum.
De Morgan
---------
$m5 # move last line to after 5th
1,$p # does it look alright?
Great fleas have little fleas
upon their backs to bit 'em
And little fleas have lesser fleas,
and so on ad infinitum.
---------
De Morgan
w # write file
143 # 143 bytes written to disk
q # quit ed
The actual operation of ed is very similar to sed, but with one very important difference: Commands in ed are not generally applied to every line, but to your current line (PS: Note that commands will dynamically change your current line; initially you're at line 1, but after 1,$p for instance, your current line is moved to the last line in the file). You can also suffix ed commands with an address, such as:
Interactively editing files in this way is very tedious, to say the least, but here is a rule of thumb that will help you out a lot: ed is not Notepad! Suppose you want to write a letter, don't write:
Hello grandpa!
==============
Hi, how are you my bearded progenitor? Is the mainframe
giving you trouble these days? I just received the floppy
disk you sent me, looking forward to reading it, once I
have managed to locate my discarded disk drive :)
Sent to you by my 4.2BSD box
Suppose you want to change "mainframe" here, to "Remington Rand UNIVAC", you would have to manually reshuffle all of the lines in order to make them line up neatly. Such cave man practices may be fine in the Windows world, but UNIX has had the ability to automatically reformat the text for you since version 1. What you want to do is write each sentence on a line by itself, and let fmt or troff do the formatting for you:
$ ed letter
?letter
a
.SH
Hello grandpa!
.PP
Hi, how are you my bearded progenitor?
Is the mainframe giving you trouble these days?
I just received the floppy disk you sent me,
looking forward to reading it,
once I have managed to locate my discarded disk drive :)
.PP
Sent to you by my 4.2BSD box
.
w
276
q
$ nroff -ms letter > temp
$ ed temp
406
/..*/= # what's the first non-empty line?
7
1,6d # delete useless empty nroff header
/Sent to you/=
8
9,$d # delete useless empty nroff footer
1,$p
Hello grandpa!
Hi, how are you my bearded progenitor? Is the main-
frame giving you trouble these days? I just received the
floppy disk you sent me, looking forward to reading it, once
I have managed to locate my discarded disk drive :)
Sent to you by my 4.2BSD box
Of course, troff is a bit overkill for this example, fmt would be much simpler (fmt < letter > temp). Lastly, use directories and regex for what they're worth. Don't write a huge file in ~/MyNotes_and-RanomIDEAS_on_UNIX_nr13_01-02-2022. Make a directory for your project, eg. ~/tmp/notes, and arrange them in short chapters, eg. ch01. (if you need information on when the file was written, use ls -l (although admittedly getting correct dates in emulated ancient UNIX systems is not so easy)). That way it's easier to manage them with ed and other standard tools, and you can easily compile your files into a single file when needed: cat ~/tmp/notes/ch* > unixbook.