[TUHS] Warner's Early Unix Presentation
robpike at gmail.com
Sun Feb 9 07:50:47 AEST 2020
> Yes. I'd only mean that pwb enabled people to start writing real,
> non-trivial shell scripts. There's other scripts in the tree prior to
> Bourne Shell... There's several 'runit' scripts that look to build things
> pre-make. There's also sources to 'goto.c' which implemented 'goto label'
> by rewinding stdin until it finds the label then exiting (I presume the
> older shell would then start reading again from stdin). Or maybe I've
> totally missed the point of s1/goto.c... there's no comments in it. It is a
> bit of a stretch, though, you're right.
That's how goto worked, yes.
The flow from PWB back to the main research line was a trickle at best. We
>> had bad NIH in 1127.
> That matches other sources I've seen: bug fixes flowed into research
> relatively easily. Performance fixes sometimes (though often not). Some
> drivers did. And only the occasional program. It's my belief that this slow
> level of flow is why AT&T shifted from the Research line to the Unix/TS
> line and merged Unix/TS and PWB into Unix/TS 3.0 (System III was 3.0.1) and
> roped other internal lines into Unix/TS 4.0 and/or System V.
I think the SysV/Research split is just another variant of NIH and separate
organizations. The development folks did what they did because it helped
them (or perhaps just to have fun?). Features in CB Unix bothered us (like
the way init worked) and although we were pressured to take them, we
resisted. USG was more accommodating. They (USG, Unix Support Group) were
just that: a support group, and they were under immense pressure from their
users in the Bell System to add features. There was outright mockery from
us at how complex stty became, and then the ultimate insult arrived, ioctl.
So System V was theirs, managed by them, owned by them. Occasionally we'd
go to meetings there to try to convince them to do something differently. I
remember a meeting where I tried to talk them out of some truly awful
shared memory or IPC thing, but the details are hazy. I'm sure they ignored
me anyway; in general they didn't listen to us unless their users were
asking for something we had.
> I also now wonder if we got the Bourne Shell because of NIH or because
> there was some clear technical defect in pwbsh that Steve Bourne was
> correcting... There were no env vars before V7, and I haven't looked at the
> pwb sh to see how that issue was handled. I'll have to also include the
> 'pump' operator in future talks.
Mashey's shell was better than the v6 shell, no question, but it was still
pretty clunky and undisciplined. If I remember right, it was a hacked up v6
shell, but I'm not sure.
Steve Bourne, who understands formal languages and was (clearly!) a fan of
Algol 68, decided a more structured approach was necessary. People malign
the look of the code, but his research shell was lovely. For v8 I ripped
the IF ELIF macros out; they were just sugar I could scrape off. I put in
shell functions, which Steve had wanted to do anyway, made them exportable
(fought for that hard at a POSIX meeting, with Ken) and did some cleanups
to the printing etc. so it worked well when you cut and paste from the
terminal. All that was easy to do because the code was so clean. I learned
a lot working on that program. The parser is a jewel. I still think it's a
great piece of code, and I miss the v8 shell every day. The GNU "Bourne
again" shell is missing all that stuff I did.
Unfortunately, Steve's memory allocation trick, mallocking on faults, isn't
portable, and I suspect the code will never run on a modern OS. Tom Duff's
rc was done as a reaction to the shell being, despite its other glories,
still a macro language. But that's another story.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the TUHS