TUHS December 2020

tuhs@tuhs.org

56 participants
43 discussions

Re: [TUHS] The 2038 bug...

by M Douglas McIlroy

> I'll be (G-d willing) 79 then; I hope around, but I also hope not > overly involved with computers. >From the vantage point of 88, I can attest to the permanence of computing's grip. I guess the key word is "overly". The only code I've written in the last couple of weeks is a few lines of PostScript to touch up my seasonal map/greeting card, the creative part of which is at www.cs.dartmouth.edu/~doug/2020map.pdf. Doug

3 years, 11 months

Which years saw the introduction of (1) #! and (2) symbolic links

by ron minnich

I think I remember but want to ask the experts.

3 years, 11 months

Re: [TUHS] Fwd: For the archives: UNIX/24V for the Harris /6 Docs

by jnc＠mercury.lcs.mit.edu

> Bill passed away this summer - you may have seen his epic farewell > message. Anyone have a copy of this? I did a Web search, but all I could find was the Subject line ("public static final void goodbye ()"). holding back the night with its increasing brilliance the summer moon -- Yoshitoshi's death poem Noel

3 years, 12 months

Fwd: For the archives: UNIX/24V for the Harris /6 Docs

by Warren Toomey

All, a while back Tom Lyon sent me the following e-mail and I'd been sitting on my hands, but I've finally placed these two theses in the Unix Archive at https://www.tuhs.org/Archive/Documentation/Theses/ Thanks Tom! Cheers, Warren -------- Forwarded Message -------- Hi, Warren - as you may know, Bill Shannon and Sam Leffler ported UNIX to the Harris /6 minicomputer at Case Western. Bill passed away this summer - you may have seen his epic farewell message. Anyways, that prompted me to get the CWRU librarians to scan copies of Shannon's and Leffler's theses where they describe the work. It took a while due to Covid, but I have them now (attached). There is a copyright disclaimer at the end of each, but it allows for research purposes, which is all that I can imagine this being used for. Please give them a home in the archives, and announce as you please. - Tom

3 years, 12 months

Re: [TUHS] Style and diction commands available?

by Richard Salz

I pulled copies from Clem's recommendation, > The DWB distribution from the Toolkit is not around to my knowledge, but: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd look for the diction and style directories, which should be close. I got them to compile with modern C. Then I found that FSF has their own rewrites.https://www.gnu.org/software/diction/ It's only three years old, not 30. :) Just FYI.

3 years, 12 months

Re: [TUHS] History of the UNIX Beard

by jnc＠mercury.lcs.mit.edu

> From: Tyler Adams > We all know and love the UNIX beard, but I can't find anything on how > the beards started other than an old photo of Ken and Dennis I'm not sure the term is Unix-specific. At a fairly early stage, people who worked on the ARPANET/Internet (when PDP-10's were still the 'usual' host, and Unix systems were just starting to beceome common) were jokingly known as 'network grey-beards': the prototypical one being Jon Postel. (Vint Verf's beard was too tidy to qualify, IIRC!) Noel

4 years

Algol 68 and Unix (was cron and at ...)

by M Douglas McIlroy

> Sometimes I wonder what would have happened if A68 had become the medium-level language of Unix My knowledge of A68 comes from reading the official definition back in the day. It took effort to see the clarity of the design through the fog of the description. Until more accessible descriptions came along (which I admit to not having seen) it would have been a big barrier to acceptance. A68 was very much in the air (though not much on the ground) in the early days of Unix, as was PL/I. Although we had implemented and used PL/I for Multics, it was never considered for Unix due to Its size and the rise of other attractive languages during the 6-year gestation of Multics. BCPL had the most influence, particularly in its clever identity a[i] = i [a] = *(a+i).It was OK to write 2[x], which served to implement structs like this: field=2; field[x]=3. (Actually the BCPL indirection operator was not *. Dennis borrowed the more perspicuous *from the SAP assembler for IBM 700-series machines.) >From Algol 68 Dennis borrowed addition operators like +=, though at first he unwisely reversed their spelling, underestimating the inherent hazard of a=-b. He rejected A68's automatic dereferencing as too inflexible. He considered whether semicolons should be separators as in Algol, or terminators as in PL/I. (Separators are more convenient for macro substitution, but macros were not in the original design.) He also considered making statements and expressions mutually recursive as in A68. My recollection is that his choices were finally based on a guess about user acceptance--how many radical innovations would prospective users buy into. Perhaps Ken would have more to say about this, I tried to persuade Dennis to provide simultaneous assignments like a,b = b,a, In the end, the comma operator got hijacked for a partial realization of embedded statements.(We could still get parallel assignment by, interpreting the existing {a,b,c} syntax as an lvalue thus: {a,b,c}={b,c,a}.) Then came Steve Bourne, with real experience in A68. Its influence on the shell, including the story of do...done, has often been told. It shows up most vividly in the condition part of if and while statements. Doug

4 years

Were cron and at done at the same time? Or one before the other?

by M Douglas McIlroy

This pair of commands exemplifies a weakness in the way Unix evolved. Although it was the product of a shared vision, It was not a product-oriented project. Unix commands work well together, but they don't necessarily work alike. It would be nice if identifiable families of commands had similar user interfaces. However, cron and at were written by different individuals, apparently with somewhat different tastes. Unix folks were close colleagues, but had no organized design committee. Time specs in cron and at are markedly different. A more consequential example is data-field specs (or lack thereof) in sort, join, cut, comm and uniq. The various specs were recognized as "wildly incongruent" in a BUG remak. However there was no impetus for unification. To paraphrase John Cocke (speaking about Fortran): one must understand that Unix commands are not a logical language. They are a natural language--in the sense that they developed by organic evolution, not "intelligent design". Doug

4 years

sh and goto

by srbourne

Message: 4 Date: Mon, 30 Nov 2020 19:59:18 -0800 (PST) From:jason-tuhs@shalott.net To:tuhs@minnie.tuhs.org Subject: Re: [TUHS] The UNIX Command Language (1976) Message-ID: <alpine.LRH.2.23.453.2011301946410.14253(a)waffle.shalott.net> Content-Type: text/plain; charset="utf-8"; Format="flowed" > "The UNIX Command Language is the first-ever paper published on the Unix > shell. It was written by Ken Thompson in 1976." > > https://github.com/susam/tucl Thanks for that. This reminded me that the Thompson shell used goto for flow control, which I had forgotten. Bourne commented on the omission of goto from the Bourne shell, "I eliminated goto in favour of flow control primitives like if and for. This was also considered rather radical departure from the existing practice." Was this decision contentious at all? Was there a specific reason for goto's exclusion in the Bourne shell? Thanks. -Jason At the time it may have raised a few eyebrows but I don't recall much discussion about it then. My email tracks at the time don't mention it. Doug McIlroy or Steve Johnson (or Ken) on this forum might recall differently. At the time scripts were not that complicated and so error recovery to a far off place in the script was not common. As an aside I did persuade Dennis to add "setjmp" and "longjmp" so the shell code itself could recover from some kinds of script errors. So I did not have a "religious" aversion to "goto" at the time. Steve

4 years

sh and goto

by M Douglas McIlroy

> Bourne commented on the omission of goto from the Bourne shell ... > Was this decision contentious at all? Was there a specific reason for goto's exclusion in the Bourne shell? I don't believe I ever used a shell goto, because I knew how it worked--maybe even spinning a tape drive, not too different from running a loop on the IBM CPC. There you stood in front of the program "read head" (a card reader), grabbed the "used" cards at the bottom and put them back in the top feed. Voila, a program loop. The shell goto differed in that it returned to the beginning by running the tape backward rather than going around a physically looped path. And you didn't have to spin the tape by hand. It also reminds me of George Stibitz's patent on the goto. The idea there was to stop reading this tape and read that one instead. The system library was a bank of tape readers with programs at the ready on tape loops . (This was in the late 1940s. I saw the machine but never used it. I did have hands-on experience with CPCcards.) Doug

4 years

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 December 2020