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.

-rob