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
Lyndon Nerenberg:
Do you still consider '^' the shell's inter-command pipe character?
======
No. By the time I first used UNIX, | was well-established as
the official pipeline character; ^ was just a quirky synonym.
I had the impression somehow that ^ was there just to make
life easier on the Model 33 Teletype, which had no | key.
Digging into old manuals, ^ and | appear simultaneously, in
sh(1) in the Fourth Edition. Pipelines first appeared in
3/e, though with a clumsier syntax (not supported by
any current shell I know): where we would now type
ls | wc
the original syntax was
ls > wc >
The trailing > was required to tell the shell to make a pipeline
of the two commands, rather than to redirect output to a file
named wc. One could of course redirect the final command's
output to a file as well:
ls > wc > filecount
Even clumsier: where we would now type
ls | pr -h 'Look at all these files!'
the 3/e shell expected
ls > "pr -h 'Look at all these files!'" >
because its parser bound > to only the single following word.
The original syntax could be reversed too:
wc < ls <
The manual implies this was required if the pipeline's
ultimate input came from a file. Maybe someone with more
energy than I have right now can dig out the source code
and see.
I was originally going to use an example like
who | grep 'r.*' | wc -l
but the old-style version would be anachronistic. There
was no grep yet in 3/e, and wc took no arguments.
I do still have the habit of quoting ^ in command arguments,
but that's still necessary on a few current systems; e.g.
/bin/sh on Solaris 10. Fortunately, that makes it easier
to remember to quote ! as well, something required by the
clumsy command-history mechanism some people like but I don't.
(I usually turn off history but occasionally it gets turned on
by accident anyway.)
Norman Wilson
Toronto ON
>> From: Mark Longridge <cubexyz(a)gmail.com>
>> I thought you folks might be interested in looking at the changes I had
>> to make. It was a bit harder than the port to v6 but porting to v6
>> first did make things a bit easier.
> To save me from poring over 'diff' output :-), what (at a high level) were
> the changes you had to make to get it to run on v5?
> Noel
Briefly the differences were these:
modern to v7: remove all references to void
no vi on v7, v6, and v5 so using ed instead.
no conditional compilation so no way to make a truly universal version
which works on everything.
v7 to v6: use iolib instead of stdio: fopen -> copen, fclose ->
cclose, fgetc -> cgetc, fputc -> cputc
use int (no long or short in v6)
call to srand uses different argument
copen returns an int instead of a file pointer
no strcat in v6 so the function had to be added
v6 to v5: no iolib: fopen -> creat + open, copen -> open, cgetc ->
read, cputc -> write, cclose -> close
no scanf in v5 so I used the source for gets from v7 instead
getchar() leaves a newline in the buffer so I added an extra call to
getchar() immediately before each call to gets
The size of the unirubik executable was 8K for modern Linux, 10K for
v7, 10K for v6, and 5492 bytes for v5.
Generally I was a lot slower trying to edit files with ed rather than
vi but I'm a lot better with ed now. There wasn't really much unix v5
code to look at and I found the v5 manual a bit spartan.
Mark
