> Interesting, but then nobody did run a modern shell on one of these machines or
> everybody did type slowly, so the character lossage problem did not occur.
I'm afraid I don't get the point, apparently something about the
relative performance of stream- and non-stream tty drivers. How
do shells get into the act? And didn't uucp, which was certainly
not a slow typist, appear like any dial-up connection and thus
use /dev/ttyxx? (I cannot recollect, though, when dial-up uucp
finally ceased.)
DOug
Doug McIlroy:
"Re-port" may be a bit strong. Internet stuff from Berkeley
was folded into the research code (for a huge increase in
kernel size). But I think it was done by pasting Berkeley
code into local source, rather than the other way around.
====
Actually it was more nearly:
-- Adopt 4.1c BSD kernel
-- Graft in Research-specific things it was important to
keep: in particular Dennis's stream subsystem, Tom Killian's
original /proc, Peter Weinberger's early network file system
client code (the server was just a user-mode program) and
simple hackery to speed up the file system without great
fuss (make the block size 4KiB and move the free list to
a bitmap; no cylinder groups or other radical changes).
Also device drivers to support Datakit, at the time our
workhorse network. I think a file-system switch went
in early as well, spurred by having both /proc and
pjw's network file system; it wasn't used to support
multiple disk-file-system layouts, though it could have
been.
-- Outside the kernel, keep pretty much the then-current
Research commands, including Blit/5620 support, the
cleaned up and slightly-extended Bourne shell, and whatnot.
I don't think the BSD kernel when adopted had much, if any,
of sockets, Berkeley's TCP/IP, McKusick's FFS; if it did,
they were excised. Likewise any remaining trace of V7's
mpx(2) multiplexed-file IPC.
I'm going by the state the system was in when I arrived
in August 1984, plus a short note written by Weinberger
that I came across later.
TCP/IP support didn't show up until later, I think summer
1985, though it might have been a year later. The first
cut was done by Robert T. Morris (later famous for a buggy
program that broke the Internet), who did several summers
as an intern; he took the code from (I think) 4.2 BSD,
and constructed some shims to fit it into the stream world.
Paul Glick later cleaned it up a lot, removing the need
for most of the shimmery.
Further evolution followed, of course, including a
complete rewrite of the interface between drivers
(device, file system, and stream) and the rest of the
system, which made configuration much more straightforward.
Also a rampage on my part to identify code that was no
longer useful and kick it out; I took special pleasure
in removing ptrace(2) (even though I had to change adb
and sdb first to use /proc).
But that was all later.
Norman Wilson
Toronto ON
Gerard Holzmann took the true and false commands as
the jumping-off point for "Code Inflation", an
installment of his "Reliable Code" blog and column
in IEE Software. An informative, but depressing, read:
http://spinroot.com/gerard/pdf/Code_Inflation.pdf
Doug
Norman wrote
The earliest stream-I/O-system-based tty driver I'm aware of was
already in the Research kernel when I interviewed at Bell Labs
in early 1984. I have a vague memory that it was a couple of
years older than that, but I cannot find any citations to
back up either of those memories.
Dennis described streams in the special Unix issue of the
BSTJ, Oct 1984, and noted that "it runs on about 20 machines in
... Research ... Although it is being investigated in other
parts of AT&T Bell Laboratories, it is not generally available."
The manuscript was received October 18, 1983.
Doug
Doug
Because of the design bug I mentioned, I searched for UNIX sources from AT&T
that include streams support, but could never find any.
=====
None of the Research systems after 32/V was ever distributed except
to a handful of sites under site-specific letter agreements that
forbade redistribution.
This is a bug, not a feature, but there it is. It was easy to get
approval to write a paper, much harder to get permission to distribute
code, especially when the code in some way overlapped the Official
Product.
Warren and I (and Dennis, when he was still alive) hoped to do
something about some years back, but it's a lot harder than it used
to be because it is harder to find a corporate entity that is
confident enough to give permission, even for stuff that is so old
that it is unlikely to have a trumppenceworth of commercial value.
Then IBM vs SCO intervened, and now things are even more fragmented.
There may be other efforts under way now and then to negotiate the
legal minefield. I wish them all well, and will help them where I
can.
Norman Wilson
Toronto ON
I'm not sure of the point of this mine-is-bigger-than-yours argument, but:
The earliest stream-I/O-system-based tty driver I'm aware of was
already in the Research kernel when I interviewed at Bell Labs
in early 1984. I have a vague memory that it was a couple of
years older than that, and was first implemented in a post-V7
PDP-11 system; also that I had heard about it first at a USENIX
conference in 1982 or 1983; but I cannot find any citations to
back up either of those memories.
I do know that I'd heard of it while I was still working at Caltech,
because I remember thinking about what a good idea it was and
about possibly trying to do my own version of it, but I never did.
I left Caltech at the end of June 1984, spent the following month
touring nearly the entire Amtrak long-distance network in a single
long reservation (it was possible to do that with surprisingly few
overnight stops off the train in those days), and started at Bell
Labs at the beginning of August.
Norman Wilson
Toronto ON
It sounds like my understanding of the different 4.1x versions is
just mistaken. If 4.1c had FFS and sockets, the kernel on which
V8 was built must have been an earlier 4.1x.
I believe the reason for adopting that kernel, rather than sticking
with 32/V, was exactly to get paging support. There was a competing
32/V descendant with paging, written by John Reiser at Holmdel, which
I gather was thought by many to be much cleaner technically; e.g. he
unified the block-device buffer cache and the memory-page cache, and
implemented copy-on-write paging rather than resorting to the messy
vfork. I have heard that there was considerable argument and
hand-wringing over whether to use Reiser's kernel or the BSD one.
It all happened well before I arrived, and I don't know what the
tradeoffs were, though one was certainly that Reiser's management
didn't support his work and nobody in 1127 was keen to have to take
it over.
Norman Wilson
Toronto ON
Joerg Schilling:
The colon was introduced by AT&T around 1983. It was used for Bourne Shell
scripts. Some of these scripts made it into SVr4 and caused problems with
non-Bourne compatible other shells.
====
Interesting. I never knew of that convention. I remember seeing
shell scripts with a : at the front, but thought that was just to
make sure the first character wasn't # even if the script began with
a comment.
Since some here had never heard of the #-means-csh convention, I
should perhaps explain about :. In pre-Bourne shells that used the
simple external control-flow mechanisms that I think were discussed
here a few months ago, : was used to mark a label: goto(1) would
seek to the beginning of its standard input, then read until it
encountered a line of the form
: label
with the desired label, then exit with the seek pointer at the first
character of the following line.
: was a no-op command; I forget whether it was implemented within the
shell or externally. Either way, that made it useful as a comment
character, but somewhat clumsy: it was just a command, with no
special parsing rules attached. A comment using : had to begin at
a command boundary, and its arguments were parsed in the normal way:
rm -rf * : you don't want to do this
was probably not what you wanted, instead you had to type
rm -rf * ; : "you don't want to do this"
or the like.
csh used # as a comment character from the beginning. Bourne
adopted it too.
Norman Wilson
Toronto ON
Random832:
The existence of cd as a real command is a bit silly (Ubuntu doesn't
seem to bother with it), but it is technically required by the standard.
===
Just for the record, Fedora 21 supplies /bin/cd, as part
of package bash-4.3.42-1. Interestingly, it is a shell
script:
lu$ cat /bin/cd
#!/bin/sh
builtin cd "$@"
lu$
As has been said here, it's hard to see the functional point.
Others have remarked on the continued life of /bin/true and
/bin/false. There are some who use those as shells in /etc/passwd
for logins that should never actually be allowed to do anything
directly. I have no strong personal feeling about that, I'm just
reporting.
And to be fair (as has also already been displayed here), the
copyright notice inserted in the once-empty /bin/true was hundreds
of bytes long, not thousands. Let us call out silliness, but let
us not make it out as any sillier than it actually is.
Norman Wilson
Toronto ON
UNIX old fart and amateur pedant
