TUHS

tuhs@tuhs.org

46 participants
6502 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

3 years, 5 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. > >

3 years, 5 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

3 years, 6 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

3 years, 6 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

3 years, 6 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

3 years, 6 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/ - -------------------------------------------------------------------------------

3 years, 6 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>

3 years, 6 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

3 years, 6 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)

3 years, 6 months

Re: [TUHS] Book Recommendation

by Douglas McIlroy

>>I take credit as a go-between, not as an inventor. Ken Knowlton >>introduced the notation ABC in BEFLIX, a pixel-based animation >>language. > In BEFLIX, 'ABC' meant what, exactly? Offsets from pixel locations? It meant exactly what A->B->C means in C. Pixels had properties, represented in data structures. One valid data type was pointer. Incidentally, another BEFLIX innovation was the buddy system for dynamic storage allocation. Doug

3 years, 6 months

Re: [TUHS] Book Recommendation

by Douglas McIlroy

While waiting to see the full text, I've poked around the index for subjects of interest. It certainly is copious, and knows about a lot of things that I don't. The authors make a reasonable choice in identifying the dawn of "modern computing" with Eniac and relegating non-electronic machines to prehistory. Still, I was glad to find the prophetic Konrad Zuse mentioned, but disappointed not to find the Bell Labs pioneer, George Stibitz. Among programming languages, Fortran, which changed the nature of programming, is merely hinted at (buried in the forgettable Fortran Monitoring System), while its insignificant offspring PL/I is present. (Possibly this is an indexing oversight. John Backus, who led the Fortran project, is mentioned quite early in the book.) Algol, Lisp, Simula and Smalltalk quite properly make the list, but Basic rates more coverage than any of them. C, obscurely alphabetized as "C language", is treated generously, as is Unix in general. Surprisingly there's almost nothing in the index about security or privacy. The litany of whiggish chapters about various uses of computers needs a cautionary complement. "The computer attracts crooks and spies" would be a stylistically consistent title. Doug

3 years, 6 months

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

by Douglas McIlroy

> My belief is that perl was written to replace a lot of Unix pipelines, I understand Perl's motive to have been a lot like PL/I's: subsume several popular styles of programming in one language. PL/I's ensemble wasn't always harmonious. Perl's was cacophony. Doug

3 years, 6 months

Re: [TUHS] Book Recommendation

by John Foust

At 11:00 AM 11/16/2021, Douglas McIlroy wrote: >>> The former notation C(B(A)) became A->B->C. This was PL/I's gift to C. > >> You seem to have a gift for notation. That's rare. Curious what you think of APL? > >I take credit as a go-between, not as an inventor. Ken Knowlton >introduced the notation ABC in BEFLIX, a pixel-based animation >language. In BEFLIX, 'ABC' meant what, exactly? Offsets from pixel locations? - John

3 years, 6 months

Speaking of groups: JHU Ownership

by Ron Natalie

A private message with Uh, Clem reminds me of another quaint piece of UNIX group history: JHU Ownership. The original V6 kernel and file systems used a char for UID and GID. This meant that you could only have 255 (plus the root user) distinct users on the machine. The JHU PDP-11/45 was used for the EE classes and we had more than that many users. The kernel was modified to check if the GID was 200 or greater. If it was, that was taken along with the UID to be part of the user identity. We gave all the class accounts such GIDs. Of course, we had to be careful about newgrp and fun and games with setuid/setgid (both the system call and the bits on the executables). I spent a lot of my time looking for exploits there and fixing them once I (or someone else) found them.

3 years, 6 months

Will someone please explain the history and usage of gpasswd / newgrp / sg?

by Grant Taylor

Hi, Will someone please explain the history and usage of gpasswd / newgrp / sg? I've run across them again recently while reading old Unix texts. I've been aware of them for years, but I've never actually used them for anything beyond kicking the tires. So I figured that I'd inquire of the hive mind that is TUHS / COFF. When was the concept of group passwords introduced? What was the problem that group passwords were the solution for? How common was the use of group passwords? I ran into one comment indicating that they used newgrp to work around a limitation in the number of (secondary) groups in relation to an NFS implementation. Specifically that the implementation of NFS they were using didn't support more than 16 groups. So they would switch their primary group to work around this limit. Does anyone have any interesting stories related to group passwords / gpasswd / newgrp / sg? -- Grant. . . . unix || die

3 years, 6 months

Double posting

by jnc＠mercury.lcs.mit.edu

Can people **please** send posts to one of these two lists, only? Having to go through and delete every other post (yeah, I know, I could relete _all_ messages to either list, since they are archived, but old habits are hard to break) is _really_ annoying. OK, I can see sending an _initial_ query to both lists, to get it to as wide a circle as possible: _but_ BCC at least one of them, to prevent lazy people just hitting 'reply all' and thereby sanding out multiple copies of their reply. Thank you. Noel

3 years, 6 months

Book Recommendation

by Clem Cole

I wanted to pass on a recommendation of a new book from MIT Press called: “A New History of Computing” by Thomas Haigh and Paul Cerruzzi, ISBN 978-0-262-54299-0 Full disclosure, I reviewed a bit of it for them and have been eagerly awaiting final publication. I do expect a lot of the readers of this mailing list will enjoy it. They did a super job researching it and it’s very complete and of course, interesting. FWIW: the work of a number people that are part of this list is nice chronicled. Clem -- Sent from a handheld expect more typos than usual

3 years, 6 months

First(?) C Reference Manual

by Alan Glasser

I have been looking for some time for a C Reference Manual from early 1973 (or late 1972) where Dennis comments that multiple array subscripts will eventually have Fortran-like syntax with commas separating rather than multiple sets of square brackets. That was the first C manual I had back when I first learned the language. Silly me, I discarded it when a newer one was issued, not realizing the historical significance of the earlier one. - Alan

3 years, 6 months

Re: [TUHS] macro returning a value?

by Douglas McIlroy

> Is there a trick to make a macro or string return a value? I know what you mean. Though a string does return a value, it can't compute an arithmetic result. Alternatively, a macro, which can use arithmetic, can only return the result as a distinct input line. (That might be overcome by a trick with \c, but I don't see one right off.) Though I have no useful advice about this dilemma, it does spur memories. I wrote the pre-Unix roff that was reimplemented on Unix and then superseded by Joe Ossanna's nroff. Joe introduced macros. Curiously, I had implemented macros in an assembler so early on (1959) that I have (incorrectly) been cited as the father of macros, yet it never occurred to me to put them in roff. Joe's work inspired me to add macros to pre-Unix roff. I did one thing differently. A macro could be called the usual way or it could be called inline like an nroff string. The only difference was that a macro's final newline was omitted when it was expanded inline. That implementation might have helped with the dilemma. Doug

3 years, 6 months

retro-fuse support for v7 filesystems

by Jay Logue

Just a quick note to announce that the retro-fuse project now supports mounting seventh-edition file systems for read and write on Linux and MacOS. As was done for v6, the project incorporates the actual filesystem code from v7 Unix, lightly modernized to run in user space on current systems. The code is available on github for anyone who's interested: https://github.com/jaylogue/retro-fuse --Jay

3 years, 6 months

First Edition 50th publication anniversary...

by Perry E. Metzger

According to https://www.bell-labs.com/usr/dmr/www/1stEdman.html : The first edition of the Unix Programmer's Manual was dated November 3, 1971 So, Happy 50th Birthday, First Edition! Perry

3 years, 6 months

Question about Unix adminstration

by joseph turco

Hello all, I was wondering if there exists a book on Unix administration, specifically for v7. I have the Unix programmers book already. Regards Joseph Turco

3 years, 6 months

Re: [TUHS] Unix NCP protocol stack for ARPANET

by jnc＠mercury.lcs.mit.edu

> From: "Ron Natalie" > However, the last NCP host table shows this statistic for DEC machines > on the NCP Arpanet > ... > PDP11 (MOS): 11 > PDP11 (MINITS); 10 Hi, which host table was this that you're looking at? I'm pretty sure there was no MINITS NCP ('NCP' in the sense of 'Initial Connection Protocol (ICP)' and 'ARPANET Host-to-Host Protocol (AHHP)' - see below). There was _certainaly_ no MINITS machine on the ARPANET at MIT (the birthplace of MINITS). To confirm, I looked at a major MINITS source repository, here: https://github.com/PDP-10/its/tree/master/src/mits_s and saw nothing like that. (Not even an 1822 interface driver.) If you look there, you _will_ see things labelled 'NCP', but this is just a terminological affliction among the CHAOS people, to whom 'NCP' apparently meant 'protocol implementation' or 'network code'. Also, implementations of the 'Host-to-IMP Protocol (HIP)' are _not_ NCP either; there was an HIP implementation in the C Gateway, but that was as IP router, one that could connect to an IMP. IF IT DOESN'T HAVE AHHP, IT"S NOT NCP. Also, I was intimately familiar with MOS, and neither of the two earliest applications that ran on it (the TIU, and the Port Expander, both of which I have the source code for) had any NCP. I looked at a lot of the MOS 'NCP" listings in a old host table (see here: https://gunkies.org/wiki/Talk:Network_Control_Program for details) and concluded that the MOS 'NCP' entries were all 'confused'. > From: Clem Cole > I was under the impression, that you folks at MIT did a ChaosNet > interface, IIRC, so there may have been some sort of conversion on > your LAN, but I really doubt there was a real NCP running. The AI Lab did both i) a LAN called CHAOS (4 Mbit/seccond CSMA-CD over CATV cable) and ii) a protocol family callled CHAOS (which later ran over XDI Ethernet). I'm not sure that any of it has any relvance to what's under discussion here. > But there was a Rand stack around the same time and III think > Holmgren ended up at UCSB after his time at UICI. Im fairly sure there > was cross polinartion but I don't know how much. I looked through my V6 Unix NCP, but although there were some RAND #ifdefs, I didn't see anything about Rand (except that the MMDF is noted as being based on something done at Rand). I retain the distinct impression that all V6 Unix NCP machines were running some descendant of the UIUC code. NOSC seems to have served as a distro center at one point, see: https://minnie.tuhs.org//cgi-bin/utree.pl?file=SRI-NOSC/new/dist.log but I can't tell who they were sending it too. (We never tried to get it running at MIT since we were out of IMP ports. By the time we got another IMP, we had IP running on the -11 and NCP was done anyway.) As for UCB, there are a bunch of UCBUFMOD #ifdef's, not sure what that was about. > As for other NCPs, PARC had MAXC on the net, but I thought it had > originally a DG Nova front end that was replaced with an Alto. No, Maxc1 had a Nova, Maxc2 had an Alto. > From: Paul Ruizendaal > they started with 32V in the Fall of 1979, and ported UIUC's NCP code > to it Thanks for straightening that out. I had a vague memory that there were a few VAXen that ran NCP, but wasn't sure. > 2. Note that the BBN TCP worked over NCP as its primary transport. Your terminology is confused. TCP _never_ ran 'on' NCP; they were _alternative_ protocol stacks on top of IHP (on the ARPANET). No AHHP, no NCP. > The driver is still there if you look That acc.c is a driver for the ACC 1822 interface; it includes bits of IHP ("Try to send 3 no-ops to IMP") but I don't think it includes the complete IHP. There are other BSD 1822 device drivers, e.g.: https://minnie.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/sys/pdpif/if_sri.c That's the BSD2.11 Stanford/SRI 1822 device driver. Noel

3 years, 6 months

Anyone have a modem wired up?

by John Floren

I'm experimenting with my PiDP-11; I think I may have my modem set up properly to accept incoming calls, but with only one phone line I'm unable to test it. If anyone with a modem is willing to help me test, send me a message off-list and I'll give you my phone number & some login details. john

3 years, 6 months

Jump to page:

2025

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