TUHS November 2021

tuhs@tuhs.org

55 participants
32 discussions

by Douglas McIlroy

The following remark stirred old memories. Apologies for straying off the path of TUHS. > I have gotten the impression that [PL/I] was a language that was beloved by no one. As I was a designer of PL/I, an implementer of EPL (the preliminary PL/I compiler used to build Multics), and author of the first PL/I program to appear in the ACM Collected Algorithms, it's a bit hard to admit that PL/I was "insignificant". I'm proud, though, of having conceived the SIGNAL statement, which pioneered exception handling, and the USES and SETS attributes, which unfortunately sank into oblivion. I also spurred Bud Lawson to invent -> for pointer-chasing. The former notation C(B(A)) became A->B->C. This was PL/I's gift to C. After the ACM program I never wrote another line of PL/I. Gratification finally came forty years on when I met a retired programmer who, unaware of my PL/I connection, volunteered that she had loved PL/I above all other programming languages. Doug

2 years, 4 months

IBM Unix

by Ron Natalie

I remember getting an early RT without being given the root password. Now there hadn’t been too many Unix boxes I wasn’t able to break into. The Rt you could turn the key to the wrench symbol and get into the maintenance menus. Selecting to view some document which was displayed with more and that you could bang a root shell out of. > On Nov 24, 2021, at 14:42, Clem Cole <clemc(a)ccc.com> wrote: > > > > >> On Wed, Nov 24, 2021 at 1:43 PM Larry McVoy <lm(a)mcvoy.com> wrote: >> SMIT - just say no. > There were a number of things IBM did well with AIX so I'm not quite so glib knocking everything from them. > >

2 years, 4 months

Re: [TUHS] Book Recommendation

by Norman Wilson

Larry McVoy: Say hi to Barry for me, I knew him back in the UUCP days, he was always pleasant. ==== And for me. Knew him back in my DECUS days. Also tell him that since he runs the World, it's all his fault. Norman Wilson Toronto ON

2 years, 4 months

Two anecdotes

by Alan Glasser

Here are two anecdotes that Doug suggested I share with TUHS (I am new to TUHS, having joined just last month). *First*: *The creation of access(2).* [Marc Rochkind documented a version of this on page 56 of his book *Advanced Unix Programming* (1985, First Edition) discussing link(2). The footnote on that page says "Alan L. Glasser and I used this scheme to break into Dennis Ritchie and Ken Thompson's system back in 1973 or 1974."] Doug pointed out that the timing was probably later, as access(2) was not in the Sixth Edition release, but probably right after the release (after May 1975?). It arose from a discussion I was having with Marc, with whom I worked on SCCS and other PWB tools. We were discussing some mechanism that would require moving directories (actually, simple renaming) in a shell procedure. I told Marc that only root could make links to directories or unlink directories, but he told me that he has renamed directories with the mv command. I said then mv must be setuid to root, so we looked, and, of course, it was. I then looked at the source code for mv and quickly saw that there was no attempt to check permission on the real uid. So I told Marc it would allow anyone to become root. He wanted to see it in action, so I logged into research (I don’t remember what our organization's shared login was). No one in our organization had root access on research. Marc and I didn't have root access on our organization's machines; Dick Haight et. al. didn't share that privilege (Dick was the manager of the super-users). I think the actual sequence of commands was: cd / cp etc/passwd tmp ed tmp/passwd 1s/^root:[^:]*:/root::/ w q mv etc etc2 mv tmp etc su mv etc tmp mv etc2 etc mv etc/as2 etc/.as2 {logout, hangup and wonder} The last bit was a test to see what was noticed about what I did. Marc and I talked for a while about it and discussed if we had any need to be root on our local machines, but couldn't think of any pressing need, but knowing we could was a bit of a comfort. After a short time, Marc suggested logging back in to see what, if anything, had been done. /bin/mv had lost setuid to root /etc/as2 was restored /etc/.as2 was nonexistent And the next day, the motd on research mentioned that there's a new syscall: access. And mv(1) now used it. *Second*: Our organization was one (out of possibly others) subject of Ken's *codenih* that he documented in his Turing Award article in CACM. As previously described, root access was closely guarded in the PWB organization and, according to Doug, freely available in research. Ken had given us a login that was shared by PWB development and we had given Ken a login to our systems. We had no root access on research and Ken had no root access on our systems. Our C compiler guy, Rich Graveman, who kept in close contact with Dennis and was always getting us the latest compiler to install, had gone to MH and came back with a tape of a new compiler. Rich, being a careful fellow, did a size on c0, c1, c2 on the files from the tape and did the same on the running compiler pieces in /lib. Lo and behold, he discovered that the new compiler from Dennis was smaller than the old compiler even though it had a whole new feature (I think it was union). So Rich did nm's on the two different c0's and discovered a name "codenih" in the old compiler that wasn't in the new one from Dennis. He logged into research, cd'ed to /usr/ken and did an ls -ld codenih, followed by a cd codenih. Was he surprised! Then he went back to a local machine and tried to login as root/codenih, which, of course, worked. He was even more surprised and told a number of colleagues, myself included. (I logged into research and printed out the source in /usr/ken/codenih. I was super impressed.) I think you misunderstood the codenih bit. As Ken had given us a (shared among a few of us) login, we had given him one. And Dick Haight refused him root access. And no one in PY had root access on research. So much for denying Ken root access on the PWB systems. Ken "infected" the PWB C compiler with codenih, which gave him free rein. I don't know how or when he first installed it, but I suspect he was aware of any extant security holes (e.g., the mv setuid root) to allow him to replace the compiler the first time. I don't know if the PWB crowd was the impetus for Ken writing codenih or if it was something he had used on others prior to us or if he ever used it on anyone else. Needless to say, Dick Haight was beside himself. I just thought it was a great feat of programming and was thrilled when he described it in CACM. Alan

2 years, 5 months

Re: [TUHS] Recreation of the PDP-7 UNIX TMG compiler compiler

by Douglas McIlroy

> I was deeply motivated by TMG. The good news is that you could say what > you wanted and it just did it. The bad news was the error handling. > Because it was recursive if you made a syntax error the program > backtracked and tried again. And again. And again. And eventually was > back at the first character of the input with nowhere to go. So it > issued one of its two messages -- "Syntax Error". This is somewhat of a caricature. If one's compilation strategy were to build an abstract syntax tree of the whole source program before emitting any object code, then things would go as Steve describes. In reality, TMG wasn't used this way. For one thing, ASTs needed too much memory. In TMG one could emit code while parsing. Typically code was generated on a statement-by-statement basis. This limited the backtracking, so even a naive "syntax error" diagnostic could be localized to the statement level. Long-distance connections, such as the branch labels in a nest of if statements, could nevertheless be realized recursively. Thus, in actual use, a TMG "grammar" was partly a parsing program and partly abstract specification. The balance of viewpoints was left to the discretion of the grammar's author. Yacc swung the pendulum toward the abstract. Doug

2 years, 5 months

> Who asked Ken for grep?

by Douglas McIlroy

I can say unequivocally that I asked Ken for grep, and the next day it was in /bin. But ... I understand now that grep already existed in /usr/ken/bin. My request was the last straw that tipped the balance from private to public. Hopefully Ken can answer whether he made it originally for himself or for Lee. Doug

2 years, 5 months

Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]

by Nelson H. F. Beebe

The discussions under this subject line have somewhat strayed from Unix heritage issues, but because several people have contributed views of assorted programming languages that mostly grew up on Unix-family systems, I decided to add this memory. Several years ago, I attended a talk by Dan McCracken (1930--2011), noted book author in computer areas, and VP and later President of the ACM (1978--1980). His talk was about programming languages, and was done in a question/answer format, with Dan offering both parts. He began: Q: In 10 years, which of the following programming languages will still be in use: Basic, Cobol, Fortran, PL/I, .... A: First of all, Basic is not a programming language. Then ... ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

2 years, 5 months

Fwd: Who asked Ken for grep?

by silas poulson

Hello, I tried asking question below awhile back - would anyone know the proper answer? Many Thanks, Silas > > Hello, > > Recently watched couple of videos[1][2] from Ken and Brian Kernighan > on the origin of grep. > > In [1], Brian suggests Lee McMahon asked Ken for grep to help with > federalist papers analysis. > > However Ken states in [2] that Doug Mcllroy asked for someway to “look > for things in files”. > > Is this just Brian misremembering or multiple people asking around similar > times? > > Many thanks, > Silas > > [1]Where GREP Came From - Computerphile > <youtube.com/watch?v=NTfOnGZUZDk> > > [2]VCF East 2019 -- Brian Kernighan interviews Ken Thompson > <https://www.youtube.com/watch?v=EY6q5dv_B-o>

2 years, 5 months

Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]

by Paul Ruizendaal

Here’s another angle on Perl, perhaps more on topic for TUHS. Let’s accept for a minute that Perl filled the void between C and shell scripts, and that there was a latent need for a scripting language like this on Unix. The shell, awk, sed, etc. had arrived at more or less fully formed versions by 1980. Perl (and TCL) did not appear until the very end of the 1980’s. What filled the gap in that decade, if anything? Ancient Unix has ‘bs’ https://en.wikipedia.org/wiki/Bs_(programming_language) but this seems to have had very little use. Paul

2 years, 5 months

Recreation of the PDP-7 UNIX TMG compiler compiler

by Phil Budne

I was a member of the team that typed in scans of PDP-7 UNIX (the first batch of scans done didn't include the shell, so I cobbled one together in March of 2016). Scans of a second batch of listings turned up and were entered two years ago (October 2019), including the original shell, and appeared to be part of Doug McIlroy's implementation of TMG (TransMoGrifier), the compiler compiler first used to implement B. In January 2020 we got confirmation that the files t1.s thru t8.s were, in fact, for TMG, but that we were missing the compiler for the TMGL language, written in TMGL and the generated code. In what is perhaps best described as a crazed act, over the past two months I've worked to recreate a working TMG environment on PDP-7 UNIX, including a B compiler in TMGL, currently available at: https://github.com/philbudne/pdp7-unix/tree/tmg A good starting place is https://github.com/philbudne/pdp7-unix/blob/tmg/misc/tmg-notes.txt which started as my collected notes, questions and findings, and I've expanded it with prose, observations and thoughts that could, at least conceivably, be of interest to those not as oriented towards self-punishment as I am. (and on that topic, if you're looking for someone to expand, contract, or otherwise deal with some seemingly intractable legacy code, let me know: http://www.regressive.org/phil/resume.html)

2 years, 5 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS November 2021