> From: Mark Longridge <cubexyz(a)gmail.com>
> The first problem I had was I couldn't just cp over all the
> /usr/source/s1 files to the new drive because of "Arg list too long"
John Cowan nailed this; as an aside, I don't know about V5, but in vanilla V6
the entire argument list had to fit into one disk buffer (I would assume V5 is
the same).
The PWB changes to v6 included a rewrite of exec() to accumulate the argument
list in swap space, so it could be much longer; the maximum length was a
parameter, NCARGS, which was set to 5120 (10 blocks) by default.
Noel
Since there's a pdf of the unix v5 man pages I figured I might as well
recreate all the necessary files to have man pages in v5.
There's a very simple thompson shell script that I used from v6 to create man:
if X$2 != X"" nroff man0/naa man$1/$2.$1
if X$2 = X"" nroff man0/naa man1/$1.1
I borrowed the assembly language source from v6 to recreate nroff for
v5. After that it was just a matter of matching the date from various
files in v4 and v6. If the date was exactly the same for a given man
page file I just copied it straight into v5. If the date was different
then I used the version in v6 and just edited it until it matched what
was shown in the v5 manual pdf.
It should also help me figure out a lot of the differences between v5
and v6. When it's all done I'll put the disk images and configuration
files on archive.org and post the URL here.
I developed a sort of philosophy for adding stuff to unix v5 which
goes beyond the v5root.tar.gz files donated by Dennis Ritchie:
No changing of cc or as.
No changing of the kernel code beyond recompiling the existing v5 code.
No changing of the existing device drivers (adding new ones is OK).
No backporting of iolib or stdio into v5.
No changing libc.
Adding userland programs is OK as long as the above rules are followed.
Mark
Ok, I was just thinking that we have a lack of Unix version 5 (and
older) source code but since the Unix v5 era was the era of
teletypewriters perhaps there could be a stockpile of old teletype
printouts somewhere. Assuming they didn't run out of paper all the
time there would have been an automatic record generated of everything
Thompson and Ritchie did. Some of those printouts must have been kept
somewhere.
Mark
Firstly, I should mention I'm using simh to simulate Unix version 5.
Well I tried to reorganize the files in unix v5. Mainly I wanted more
room on rk0 so I figured I'd create a new drive and put all the source
from /usr/source/s1 on it.
The first problem I had was I couldn't just cp over all the
/usr/source/s1 files to the new drive because of "Arg list too long"
so I figured I would just create an archive file called all.a which
would include all the files in /usr/source/s1 and copy that over.
But then I got "phase error" when I tried to keep adding files to the
archive (I had to do this in stages, e.g. ar r all.a /usr/source/s1/a*
then ar u all.a /usr/source/s1/b* etc). Phase error seemed to occur
when the archive got larger than around 160,000 bytes. So I ended up
creating 3 archive files to keep from getting "phase error".
I was wondering does anyone understand what the limits are for the cp
and ar commands?
Mark
> From: Doug McIlroy <doug(a)cs.dartmouth.edu>
> Yet a quoted "wc -l" as a bare command or (I suspect) as the first
> command in a pipeline would lead to "command not found".
I don't know about earlier versions of Unix, but FWLIW on V6 it does indeed
barf in both of these cases (just tried it).
Noel
Thanks, Norman, for reminding me of the actual pipe syntax in v3.
This reinforces the title of one history item on Dennis's
website: "Why Ken had to invent |".
I'd suppressed all memory of the fact that in the pipeline
... > cmd > ...
cmd had to be a single token. That was certainly not the intent
of my original proposal. It is understandable, though, as a
minimal hack to the existing shell syntax and its parser, which
accepted occurrences of <token and >token anywhere in a command.
The single-token rule meant that, if you wanted to supply an
option to wc in the pipeline
ls > wc >
you couldn't write
ls > wc -l >
as one would expect, but instead had to write
ls > "wc -l" >
Yet a quoted "wc -l" as a bare command or (I suspect) as the
first command in a pipeline would lead to "command not found".
What a mess!
Soon after, Ken was inspired to invent the | operator, lest
he should have to describe an ugly duckling in public at an
upcoming symposium in London.
Is it possible that the ugliness of the token hack was the
precipitating factor that gave us the sublime | ? But for
the hack, perhaps we'd still be writing
ls > wc >
Doug
> From: Mark Longridge <cubexyz(a)gmail.com>
> In Unix v6 there is a file in the TUHS archives
> V6/usr/source/s4/alloc.s
> ..
> In v5 the command "ar t /lib/libc.a" lists the files in the c library
> and that includes alloc.o
Well, at least you have the binary. Dis-assembly time! :-)
> so there should be a source file somewhere.
Ha-ha-ha-ha-HAH! You _are_ an optimist!
I'm not joking about the dis-assembly. Not to worry, it's not too bad (I had
to do it to retrieve the source for the V6 RL bootstraps - and you've got
symbols too), and you've got the V6 alloc.s to guide you - with luck, it did
not get re-written between V5 and V6, and you may have minimal (no?) changes
to deal with?
I don't know which debugger V5 has (db or cdb); if neither, you can spin up a
V6 and do the disassembly there.
Do "db alloc.o > alloc.s" and then type '0?<RETURN>' followed by a whole
bunch of RETURNs. (You can do plain 'db alloc.o' first, to see about how many
CR's you need.) Next do a "nm alloc.o" to get as many symbols as you can.
At that point, I would extract your prototype alloc.s from the emulated
machine so you can use a real editor to work on it. (You should have a way
to get files in and out of the simulated machine; that was one of the
first things I did with my V6 work:
http://www.chiappa.net/~jnc/tech/V6Unix.html
although if you're using SIMH I don't know if that has a way to import
files - a big advantage to using Ersatz-11, although one I didn't know
about when I picked it.)
You may need to go back and do a "xxx/" {with appropriate value for "xxx"}
plus a few CR's to get static constants, but at that point you should have
all the raw data you need to re-create the V5 alloc.s. Obviously, start
by having your proto-allocV5.s in one window, and compare with the
allocV6.s in another... like I said, you may luck out.
The final step, of course, is 'as alloc.s', and then 'cmp a.out alloc.o'.
Noel
> Interesting that they had both - I don't remember hearing about the 37
> but that doesn't mean much. :-)
The only model 33 on any PDP11 in Bell Labs research was the console.
Otherwise all terminals were ASCII devices. Model 37's predated Unix.
doug
Ok, I was trying to understand exactly what the alloc(III) subroutine
does in unix version 5 and I've discovered that the source code for it
appears to be missing.
In Unix v6 there is a file in the TUHS archives
V6/usr/source/s4/alloc.s so I assume there should be a
V5/usr/source/s4/alloc.s as well but I can't find it anywhere.
In v5 the command "ar t /lib/libc.a" lists the files in the c library
and that includes alloc.o so there should be a source file somewhere.
Mark
Davwe Horsfall:
I was surprised when "chdir" became "cd", but I suppose it fits the
philosophy of 2-letter commands.
======
Don't forget that the original spelling, in the PDP-7 UNIX that
had no published manual, was ch.
The 1/e manual spells it chdir. I remember that in one of
Dennis's retrospective papers, he remarks on the change, and
says he can't remember why.
I once asked in the UNIX room if anyone could recall why ch
changed to chdir. Someone, I forget who, suggested it was
because the working directory was the only thing that could
be changed: no chmod or chown in the PDP-7 days. I don't know
whether that's true.
Norman Wilson
Toronto ON
