From tih at hamartun.priv.no Tue Dec 1 01:12:04 2020 From: tih at hamartun.priv.no (Tom Ivar Helbekkmo) Date: Mon, 30 Nov 2020 16:12:04 +0100 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: (Brantley Coile's message of "Mon, 30 Nov 2020 13:36:58 +0000") References: <8b580c46-ecfb-9383-ed43-08108b3ee7bf@tllds.com> Message-ID: Brantley Coile writes: > Thank you very much! I've been looking for where Ken used the "much > needed gap" phrase. That formulation is funny - but I just got into a discussion with someone about whether ken was being intentionally funny or not. To me, it seems rather obvious that he chose that wording for the humourous effect of the double-take the reader experiences. A couple of friends of mine, though, insist that that paragraph is just clumsily written. Is he on record anywhere saying which it is? -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay From clemc at ccc.com Tue Dec 1 01:52:40 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 30 Nov 2020 10:52:40 -0500 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: <8b580c46-ecfb-9383-ed43-08108b3ee7bf@tllds.com> References: <8b580c46-ecfb-9383-ed43-08108b3ee7bf@tllds.com> Message-ID: Too bad, they did not use the UNIX tool kit like troff and eqn which are described in the paper itself, to restore it. If you were going to the trouble to make the 'md' file - it would have been just as easy to create troff source. Sigh ... get off my lawn ... Clem On Sun, Nov 29, 2020 at 10:17 PM Joachim via TUHS wrote: > Apologies if this has already been linked here. > > "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 > > > Joachim > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Tue Dec 1 02:25:30 2020 From: crossd at gmail.com (Dan Cross) Date: Mon, 30 Nov 2020 11:25:30 -0500 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <8b580c46-ecfb-9383-ed43-08108b3ee7bf@tllds.com> Message-ID: On Mon, Nov 30, 2020 at 10:54 AM Clem Cole wrote: > Too bad, they did not use the UNIX tool kit like troff and eqn which are > described in the paper itself, to restore it. If you were going to the > trouble to make the 'md' file - it would have been just as easy to create > troff source. > In fairness, the Markdown renders directly from the github web UI, but I agree that using troff/eqn would have been nice. Surely it wouldn't be that hard to massage the markdown into troff markdown. Sigh ... get off my lawn ... > I don't even have a lawn and I'm similarly distressed at the lack of homage to the past. - Dan C. On Sun, Nov 29, 2020 at 10:17 PM Joachim via TUHS > wrote: > >> Apologies if this has already been linked here. >> >> "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 >> >> >> Joachim >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Dec 1 02:37:53 2020 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 30 Nov 2020 08:37:53 -0800 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <8b580c46-ecfb-9383-ed43-08108b3ee7bf@tllds.com> Message-ID: <20201130163753.GB18187@mcvoy.com> So Clem, the fact that troff lost and LaTex won is a direct result of that walled garden that was the early days of Unix. Unless you had a Unix license, no troff for you! Which is a huge bummer, I'm a huge troff fan (especially pic, but all of the preprocessors let you see the output in your head). I wish we lived in a troff world but we don't and that is a direct result of haves (license holders) and have nots (the other 99.999999% of the world). It's not the result we would like but it is what it is. On Mon, Nov 30, 2020 at 10:52:40AM -0500, Clem Cole wrote: > Too bad, they did not use the UNIX tool kit like troff and eqn which are > described in the paper itself, to restore it. If you were going to the > trouble to make the 'md' file - it would have been just as easy to create > troff source. > > Sigh ... get off my lawn ... > > Clem > > On Sun, Nov 29, 2020 at 10:17 PM Joachim via TUHS > wrote: > > > Apologies if this has already been linked here. > > > > "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 > > > > > > Joachim > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From imp at bsdimp.com Tue Dec 1 02:38:10 2020 From: imp at bsdimp.com (Warner Losh) Date: Mon, 30 Nov 2020 09:38:10 -0700 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <8b580c46-ecfb-9383-ed43-08108b3ee7bf@tllds.com> Message-ID: On Mon, Nov 30, 2020 at 9:27 AM Dan Cross wrote: > On Mon, Nov 30, 2020 at 10:54 AM Clem Cole wrote: > >> Too bad, they did not use the UNIX tool kit like troff and eqn which are >> described in the paper itself, to restore it. If you were going to the >> trouble to make the 'md' file - it would have been just as easy to create >> troff source. >> > > In fairness, the Markdown renders directly from the github web UI, but I > agree that using troff/eqn would have been nice. Surely it wouldn't be that > hard to massage the markdown into troff markdown. > There are a few MD to troff converters, though I don't know how many will convert to -ms format that was likely used historically. And given that ms has a little more semantic info than MD does, there may be some manual steps afterwards. Even a perfect converter would likely have manual steps since it was also the custom back in the day to tweak this or that in the output... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Tue Dec 1 02:41:36 2020 From: crossd at gmail.com (Dan Cross) Date: Mon, 30 Nov 2020 11:41:36 -0500 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <8b580c46-ecfb-9383-ed43-08108b3ee7bf@tllds.com> Message-ID: On Mon, Nov 30, 2020 at 11:38 AM Warner Losh wrote: > On Mon, Nov 30, 2020 at 9:27 AM Dan Cross wrote: > >> On Mon, Nov 30, 2020 at 10:54 AM Clem Cole wrote: >> >>> Too bad, they did not use the UNIX tool kit like troff and eqn which are >>> described in the paper itself, to restore it. If you were going to the >>> trouble to make the 'md' file - it would have been just as easy to create >>> troff source. >>> >> >> In fairness, the Markdown renders directly from the github web UI, but I >> agree that using troff/eqn would have been nice. Surely it wouldn't be that >> hard to massage the markdown into troff markdown. >> > > There are a few MD to troff converters, though I don't know how many will > convert to -ms format that was likely used historically. And given that ms > has a little more semantic info than MD does, there may be some manual > steps afterwards. Even a perfect converter would likely have manual steps > since it was also the custom back in the day to tweak this or that in the > output... > Sure, but this is a fairly short paper...I bet one could do a fairly faithful reproduction of the original in a couple of hours. I may take a stab at it and send a pull request. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Dec 1 02:54:37 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 30 Nov 2020 11:54:37 -0500 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: <20201130163753.GB18187@mcvoy.com> References: <8b580c46-ecfb-9383-ed43-08108b3ee7bf@tllds.com> <20201130163753.GB18187@mcvoy.com> Message-ID: On Mon, Nov 30, 2020 at 11:37 AM Larry McVoy wrote: > So Clem, the fact that troff lost and LaTex won is a direct result of > that walled garden that was the early days of Unix. Indeed > Unless you had a Unix license, no troff for you! yes ... but ... even UNIX binary folks had troff licenses and many/most at ditroff licenses. I know Masscomp just ate $5 per CPU and included it because we did not want to mess with the older version. If you were an academic, it was free so most research academics had either the source or at least a binary on their workstations. This did not become an issue until the 386, but by that time Clark had written what would be groff. I think your observation is correct, but in practice, I don't think that was what it was. I think the academics went LaTex and that had more to do with it. LaTex was closer to Scribe for the PDP-10s and Vaxen, which had a short head lead on all them until it went walled garden when CMU sold the rights (and even its author - Brian Ried) could not use it at a Stanford. So your are right, Wall Garden certainly impacted the result, but I think it was more preference in this case. > Which is a huge bummer, I'm a huge > troff fan (especially pic, but all of the preprocessors let you see the > output in your head). Ditto to both. > I wish we lived in a troff world but we don't > Yep > and that is a direct result of haves (license holders) and have nots > (the other 99.999999% of the world). > Maybe -- I think the PC and Word was the real kiss of death, which I find even more troubling. > > It's not the result we would like but it is what it is. > +1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Tue Dec 1 04:13:06 2020 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Mon, 30 Nov 2020 13:13:06 -0500 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <8b580c46-ecfb-9383-ed43-08108b3ee7bf@tllds.com> <20201130163753.GB18187@mcvoy.com> Message-ID: <20201130181306.GG5364@mit.edu> On Mon, Nov 30, 2020 at 11:54:37AM -0500, Clem Cole wrote: > > I think the academics went LaTex and that had more to do with it. LaTex > was closer to Scribe for the PDP-10s and Vaxen, which had a short head lead > on all them until it went walled garden when CMU sold the rights (and even > its author - Brian Ried) could not use it at a Stanford. The other issue to consider is how easily could you typeset a super-complex math expression (with integrals, sigmas, matricies, etc., etc.) using eqn vs Scribe vs LaTeX. For at least some of the stuff I needed to do when I was type-setting problem set results (there was an informal competition between some of the students regarding whose homework would get redistributed by the TA's as the official problem set answer to the rest of the class), I found LaTeX easier to use than Scribe, and I had access to all three as an MIT undergraduate. Granted, that could have been a matter of personal preference, and I never did try to use eqn for that purpose. - Ted From cowan at ccil.org Tue Dec 1 04:25:46 2020 From: cowan at ccil.org (John Cowan) Date: Mon, 30 Nov 2020 13:25:46 -0500 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <8b580c46-ecfb-9383-ed43-08108b3ee7bf@tllds.com> <20201130163753.GB18187@mcvoy.com> Message-ID: On Mon, Nov 30, 2020 at 11:55 AM Clem Cole wrote: > I wish we lived in a troff world but we don't >> > Yep > I think O'Reilly was the last commercial publisher with a troff toolchain. Nowadays they accept HTMLBook (their own static subset of HTML5), DocBook, ASCIIDoc (analogous to Markdown but plain-text DocBook as opposed to plain-text HTML), Word, and in some cases InDesign or PDF. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org And through this revolting graveyard of the universe the muffled, maddening beating of drums, and thin, monotonous whine of blasphemous flutes from inconceivable, unlighted chambers beyond Time; the detestable pounding and piping whereunto dance slowly, awkwardly, and absurdly the gigantic tenebrous ultimate gods --the blind, voiceless, mindless gargoyles whose soul is Nyarlathotep. (Lovecraft) -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Dec 1 04:37:20 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 30 Nov 2020 13:37:20 -0500 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <8b580c46-ecfb-9383-ed43-08108b3ee7bf@tllds.com> <20201130163753.GB18187@mcvoy.com> Message-ID: On Mon, Nov 30, 2020 at 1:25 PM John Cowan wrote: > > > On Mon, Nov 30, 2020 at 11:55 AM Clem Cole wrote: > > >> I wish we lived in a troff world but we don't >>> >> Yep >> > > I think O'Reilly was the last commercial publisher with a troff toolchain. > I think it depends on who you are and your editor is at the said firm. Tim will still take troff as will John Waite at Pearson. That said, as Jon can tell you, Bill will not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cym224 at gmail.com Tue Dec 1 04:46:01 2020 From: cym224 at gmail.com (Nemo Nusquam) Date: Mon, 30 Nov 2020 13:46:01 -0500 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <8b580c46-ecfb-9383-ed43-08108b3ee7bf@tllds.com> <20201130163753.GB18187@mcvoy.com> Message-ID: <4259b67c-e283-3de9-2c41-7defa6a8f9b7@gmail.com> We seem to be straying into COFF-land. However... On 11/30/20 13:25, John Cowan wrote: > On Mon, Nov 30, 2020 at 11:55 AM Clem Cole > wrote: > > I wish we lived in a troff world but we don't > > Yep > > > I think O'Reilly was the last commercial publisher with a troff > toolchain. Nowadays they accept HTMLBook (their own static subset of > HTML5), DocBook, ASCIIDoc (analogous to Markdown but plain-text > DocBook as opposed to plain-text HTML), Word, and in some cases > InDesign or PDF. I wonder what Tanenbaum does these days? Prefaces of earlier versions of all his texts stated that they were written with troff. (And Springer accepts mostly LaTeX.) N. > John Cowan http://vrici.lojban.org/~cowan > cowan at ccil.org From arnold at skeeve.com Tue Dec 1 06:11:10 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 30 Nov 2020 13:11:10 -0700 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <8b580c46-ecfb-9383-ed43-08108b3ee7bf@tllds.com> <20201130163753.GB18187@mcvoy.com> Message-ID: <202011302011.0AUKBAis007581@freefriends.org> Clem Cole wrote: > > I think O'Reilly was the last commercial publisher with a troff toolchain. They stopped using troff directly well over 20 years ago. These days if you're using a markup language and their toolset it's either Asciidoc or docbook. > I think it depends on who you are and your editor is at the said firm. Tim > will still take troff I assume you mean Tim O'Reilly? He hasn't been involved in the book side of his business in decades, and as I said, troff isn't in the picture there. > as will John Waite at Pearson. They farm such things out, they don't accept it in house. Or the author can provide "camera ready copy", which these days just means PDF. > That said, as Jon can tell you, Bill will not. No idea who Bill is. Arnold From will.senn at gmail.com Tue Dec 1 07:49:39 2020 From: will.senn at gmail.com (Will Senn) Date: Mon, 30 Nov 2020 15:49:39 -0600 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: <202011302011.0AUKBAis007581@freefriends.org> References: <8b580c46-ecfb-9383-ed43-08108b3ee7bf@tllds.com> <20201130163753.GB18187@mcvoy.com> <202011302011.0AUKBAis007581@freefriends.org> Message-ID: To show how current this topic is, there's an interesting and related discussion upcoming at NYC Bug, For the Love of Troff, on Wed @ 18:45 (I'm guessing Eastern), via Zoom: https://www.nycbug.org/index?action=view&id=10678 On 11/30/20 2:11 PM, arnold at skeeve.com wrote: > Clem Cole wrote: > >>> I think O'Reilly was the last commercial publisher with a troff toolchain. > They stopped using troff directly well over 20 years ago. > These days if you're using a markup language and their toolset it's > either Asciidoc or docbook. > >> I think it depends on who you are and your editor is at the said firm. Tim >> will still take troff > I assume you mean Tim O'Reilly? He hasn't been involved in the book > side of his business in decades, and as I said, troff isn't in the picture > there. > >> as will John Waite at Pearson. > They farm such things out, they don't accept it in house. > Or the author can provide "camera ready copy", which these days > just means PDF. > >> That said, as Jon can tell you, Bill will not. > No idea who Bill is. > > Arnold -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From j at tllds.com Tue Dec 1 10:00:36 2020 From: j at tllds.com (Joachim) Date: Mon, 30 Nov 2020 16:00:36 -0800 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: Message-ID: <4f7d5d0c-ada9-278d-8c6c-cc146a9a55fd@tllds.com> I'm also forwarding this message that arrived in my mailbox. Is this **THE** Ken Thompson? Joachim -------- Forwarded Message -------- Subject: Re: [TUHS] The UNIX Command Language (1976) Date: Sun, 29 Nov 2020 21:47:16 -0800 From: Ken Thompson To: Joachim yes. the unix manual was published before that, but i dont think it was released that early. it had a manual page on the shell. this paper might be the first paper ever released outside bell labs. On Sun, Nov 29, 2020 at 7:18 PM Joachim via TUHS > wrote: Apologies if this has already been linked here. "The UNIX Command Languageis the first-ever paper published on the Unix shell. It was written by Ken Thompson in 1976." https://github.com/susam/tucl Joachim -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Tue Dec 1 10:21:51 2020 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 1 Dec 2020 11:21:51 +1100 (EST) Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: <4f7d5d0c-ada9-278d-8c6c-cc146a9a55fd@tllds.com> References: <4f7d5d0c-ada9-278d-8c6c-cc146a9a55fd@tllds.com> Message-ID: On Mon, 30 Nov 2020, Joachim via TUHS wrote: > I'm also forwarding this message that arrived in my mailbox. Is this > **THE** Ken Thompson? I think he's on this list... -- Dave From lm at mcvoy.com Tue Dec 1 12:23:05 2020 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 30 Nov 2020 18:23:05 -0800 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <4f7d5d0c-ada9-278d-8c6c-cc146a9a55fd@tllds.com> Message-ID: <20201201022305.GM18187@mcvoy.com> He is. So is Rob Pike, Doug, Steve Johnson, Steve Bourne (I got him here) pretty much all of the remaining Bell Lab luminaries except for bwk. I've tried to twist his arm, he's remained a hard nut to crack. I think the list, and he, would love it if he were here. So long as we keep it on point and move stuff like tputs to COFF right away. I suspect all of them don't want a big deal made about them, my guess is they are here to talk about Unix. Just my opinion. On Tue, Dec 01, 2020 at 11:21:51AM +1100, Dave Horsfall wrote: > On Mon, 30 Nov 2020, Joachim via TUHS wrote: > > >I'm also forwarding this message that arrived in my mailbox. Is this > >**THE** Ken Thompson? > > I think he's on this list... > > -- Dave -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From norman at oclsc.org Tue Dec 1 13:13:06 2020 From: norman at oclsc.org (Norman Wilson) Date: Mon, 30 Nov 2020 22:13:06 -0500 (EST) Subject: [TUHS] The UNIX Command Language (1976) Message-ID: <20201201031306.C1E6943F88@lignose.oclsc.org> I'm also forwarding this message that arrived in my mailbox. Is this **THE** Ken Thompson? Yes, that's the real Ken. Those who have communicated with him in the past (and didn't get a direct note as some of us did) should notice the new e-mail address, kenbob at gmail.com. Norman Wilson Toronto ON From jon at fourwinds.com Tue Dec 1 12:55:59 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Mon, 30 Nov 2020 18:55:59 -0800 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: <202011302011.0AUKBAis007581@freefriends.org> References: <8b580c46-ecfb-9383-ed43-08108b3ee7bf@tllds.com> <20201130163753.GB18187@mcvoy.com> <202011302011.0AUKBAis007581@freefriends.org> Message-ID: <202012010255.0B12tx9m389625@darkstar.fourwinds.com> arnold at skeeve.com writes: > > > That said, as Jon can tell you, Bill will not. > > No idea who Bill is. Bill Pollack, No Starch Press. From jason-tuhs at shalott.net Tue Dec 1 13:59:18 2020 From: jason-tuhs at shalott.net (jason-tuhs at shalott.net) Date: Mon, 30 Nov 2020 19:59:18 -0800 (PST) Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: <8b580c46-ecfb-9383-ed43-08108b3ee7bf@tllds.com> References: <8b580c46-ecfb-9383-ed43-08108b3ee7bf@tllds.com> Message-ID: > "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 From jon at fourwinds.com Tue Dec 1 14:03:41 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Mon, 30 Nov 2020 20:03:41 -0800 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <8b580c46-ecfb-9383-ed43-08108b3ee7bf@tllds.com> Message-ID: <202012010403.0B143feP395338@darkstar.fourwinds.com> jason-tuhs at shalott.net writes: > > 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? I don't remember if this story has been told here before or not but I got it from Steve a few months ago. Ever wonder by the shell was symmetrical with if and fi, case and esac, but then had do and done? Reason was that by the time Steve wrote the shell, Ken had written the od command and dug in his heels and wouldn't change the name. Jon From usotsuki at buric.co Tue Dec 1 19:27:09 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Tue, 1 Dec 2020 04:27:09 -0500 (EST) Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <8b580c46-ecfb-9383-ed43-08108b3ee7bf@tllds.com> Message-ID: On Mon, 30 Nov 2020, jason-tuhs at shalott.net wrote: > >> "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 My personal opinion is that the way the Bourne shell handled flow control is a lot easier to code for (since I wrote a version of COMMAND.COM, and it has to have a "goto" command, and all the hairiness that goes with needing to be able to random-seek a shell script). -uso. From txomsy at yahoo.es Wed Dec 2 01:01:05 2020 From: txomsy at yahoo.es (Jose R. Valverde) Date: Tue, 1 Dec 2020 16:01:05 +0100 Subject: [TUHS] Apple IIe Unix? References: <20201201160105.1359e68b.ref@algol> Message-ID: <20201201160105.1359e68b@algol> Somewhat late to the discussion, but GeckOS may be another curious contender. You can find more information in http://6502.org http://www.6502.org/users/andre/index.html j -- Scientific Computing Service Centro Nacional de Biotecnología, CSIC. c/Darwin, 3. 28049 Madrid +34 91 585 45 05 +34 659 978 577 From jcapp at anteil.com Wed Dec 2 01:09:14 2020 From: jcapp at anteil.com (Jim Capp) Date: Tue, 1 Dec 2020 10:09:14 -0500 (EST) Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: Message-ID: <15511090.6330.1606835354160.JavaMail.root@zimbraanteil> Is it possible the elimination of the GOTO statement in the Bourne Shell was related to a Letter to the Editor in Communications of the ACM, March 1968: "Go To Statement Considered Harmful," by E. Dijkstra. Jim From: jason-tuhs at shalott.net To: tuhs at minnie.tuhs.org Sent: Monday, November 30, 2020 10:59:18 PM Subject: Re: [TUHS] The UNIX Command Language (1976) > "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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Dec 2 01:38:21 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 01 Dec 2020 08:38:21 -0700 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: <15511090.6330.1606835354160.JavaMail.root@zimbraanteil> References: <15511090.6330.1606835354160.JavaMail.root@zimbraanteil> Message-ID: <202012011538.0B1FcLi5023858@freefriends.org> In the late 70s and early 80s, structured programming was on the ascension, but had not completely captured the minds of all computer scientists and programmers. (cf. Knuth's "Structure Programming with Goto Statements" article.) It was recognized that goto was not necessary if one had proper control structures in a language (if/else, while), and that code with no (or minimal) gotos was easier to read and understand. So this kind of thing was "in the air" when Bourne wrote the V7 shell. If he's on this list, it'd be nice to hear directly from the source. :-) HTH, Arnold Jim Capp wrote: > Is it possible the elimination of the GOTO statement in the Bourne Shell > was related to a Letter to the Editor in Communications of the ACM, March 1968: > > "Go To Statement Considered Harmful," by E. Dijkstra. > > Jim > > > From: jason-tuhs at shalott.net > To: tuhs at minnie.tuhs.org > Sent: Monday, November 30, 2020 10:59:18 PM > Subject: Re: [TUHS] The UNIX Command Language (1976) > > > "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 From toby at telegraphics.com.au Wed Dec 2 01:35:18 2020 From: toby at telegraphics.com.au (Toby Thain) Date: Tue, 1 Dec 2020 10:35:18 -0500 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: <15511090.6330.1606835354160.JavaMail.root@zimbraanteil> References: <15511090.6330.1606835354160.JavaMail.root@zimbraanteil> Message-ID: <6f7f85f6-23f9-a39f-7f1d-37d8c666822a@telegraphics.com.au> On 2020-12-01 10:09 a.m., Jim Capp wrote: > Is it possible the elimination of the GOTO statement in the Bourne Shell > was related to a Letter to the Editor in Communications of the ACM, > March 1968: > "Go To Statement Considered Harmful," by E. Dijkstra. > Broadly connected to the rise of Structured Programming -- which we take fully for granted today. The same movement, and the popularity of Pascal, which was very competitive with C as an applications language, would have motivated the inclusion of what were at the time considered "high level" control structures, in C: do/while/for and block structuring. --Toby > Jim > > > ------------------------------------------------------------------------ > *From: *jason-tuhs at shalott.net > *To: *tuhs at minnie.tuhs.org > *Sent: *Monday, November 30, 2020 10:59:18 PM > *Subject: *Re: [TUHS] The UNIX Command Language (1976) > > >> "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 From will.senn at gmail.com Wed Dec 2 01:48:49 2020 From: will.senn at gmail.com (Will Senn) Date: Tue, 1 Dec 2020 09:48:49 -0600 Subject: [TUHS] Apple IIe Unix? In-Reply-To: <20201201160105.1359e68b@algol> References: <20201201160105.1359e68b.ref@algol> <20201201160105.1359e68b@algol> Message-ID: <69809d57-fd60-8f16-cf3b-2932b3f28dfd@gmail.com> On 12/1/20 9:01 AM, Jose R. Valverde via TUHS wrote: > Somewhat late to the discussion, but GeckOS may be another curious > contender. You can find more information in http://6502.org > > http://www.6502.org/users/andre/index.html > > j > Jose, Nice find. I'm picking the machine up a week from Saturday! I figure I'll give GeckOS a try and see about Mini-Unix, per other's suggestion, as well. If I'm successful with the later, I'll share, but there's no telling when / if :). I'm not yet adept at machine language coding/decoding - but I'm getting there. Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From coppero1237 at gmail.com Wed Dec 2 02:04:03 2020 From: coppero1237 at gmail.com (Tyler Adams) Date: Tue, 1 Dec 2020 18:04:03 +0200 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: <8b580c46-ecfb-9383-ed43-08108b3ee7bf@tllds.com> References: <8b580c46-ecfb-9383-ed43-08108b3ee7bf@tllds.com> Message-ID: "The most exotic feature of the Shell is its ability to connect the standard output of one command directly to the standard input of another. *Again, neither program is aware that such things are going on.* In the example" So sad that many shell programs today break this abstraction barrier :/ Was there a watershed moment when people started doing this, or people just always couldn't resist the "convenience" of typing less? Tyler On Mon, Nov 30, 2020 at 5:18 AM Joachim via TUHS wrote: > Apologies if this has already been linked here. > > "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 > > > Joachim > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Dec 2 02:24:17 2020 From: imp at bsdimp.com (Warner Losh) Date: Tue, 1 Dec 2020 09:24:17 -0700 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: <202012011538.0B1FcLi5023858@freefriends.org> References: <15511090.6330.1606835354160.JavaMail.root@zimbraanteil> <202012011538.0B1FcLi5023858@freefriends.org> Message-ID: On Tue, Dec 1, 2020 at 8:39 AM wrote: > It was recognized that goto was not necessary if one had proper control > structures in a language (if/else, while), and that code with no (or > minimal) gotos was easier to read and understand. > This is true for simple flow control. However, when you had to break out of multiple levels, or continue not the inner loop, but the middle loop, the use of extra booleans sure made the code less understandable than a 'goto' a label that stood in for that purpose... This was something that wasn't well understood by language designers, and even today C and C++ neither have good flow control beyond the basics. Even though both break and continue could take an optional count without breaking old code.... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Dec 2 02:39:45 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 01 Dec 2020 09:39:45 -0700 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <15511090.6330.1606835354160.JavaMail.root@zimbraanteil> <202012011538.0B1FcLi5023858@freefriends.org> Message-ID: <202012011639.0B1GdjcD031722@freefriends.org> > On Tue, Dec 1, 2020 at 8:39 AM wrote: > > It was recognized that goto was not necessary if one had proper control > > structures in a language (if/else, while), and that code with no (or > > minimal) gotos was easier to read and understand. Warner Losh wrote: > This is true for simple flow control. However, when you had to break out of > multiple levels, or continue not the inner loop, but the middle loop, the > use of extra booleans sure made the code less understandable than a 'goto' > a label that stood in for that purpose... This was something that wasn't > well understood by language designers, and even today C and C++ neither > have good flow control beyond the basics. Even though both break and > continue could take an optional count without breaking old code.... Quite true. Modern Bourne shells let you supply a number to break and continue to specify how many loops to break. Ada, or maybe it was one of the Modula-X languages, let you put a label on a loop so that you could say `continue outer' or `break outer' and not need the booleans. This is something that newer languages (C#, Java, Go, ...) could have picked up but didn't, which I think is too bad. Arnold From lm at mcvoy.com Wed Dec 2 02:47:23 2020 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 1 Dec 2020 08:47:23 -0800 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <15511090.6330.1606835354160.JavaMail.root@zimbraanteil> <202012011538.0B1FcLi5023858@freefriends.org> Message-ID: <20201201164723.GT18187@mcvoy.com> On Tue, Dec 01, 2020 at 09:24:17AM -0700, Warner Losh wrote: > On Tue, Dec 1, 2020 at 8:39 AM wrote: > > > It was recognized that goto was not necessary if one had proper control > > structures in a language (if/else, while), and that code with no (or > > minimal) gotos was easier to read and understand. > > > > This is true for simple flow control. However, when you had to break out of > multiple levels, or continue not the inner loop, but the middle loop, the > use of extra booleans sure made the code less understandable than a 'goto' > a label that stood in for that purpose... This was something that wasn't > well understood by language designers, and even today C and C++ neither > have good flow control beyond the basics. Even though both break and > continue could take an optional count without breaking old code.... Probably need to move this to COFF... but. Yeah, I've tons of examples of int somefunc() { char *a = 0; int *b = 0; flat *c = 0; int ret = 0; if (something) { a = malloc(something); } else { ret = NO_SOMETHING; goto error; } // same for b, c error: unless (ret) ret = GENERIC_ERROR; if (a) free(a); if (b) free(b); if (c) free(c); return (ret); } and you can handle a lot of simple cases that way. But sometimes the unraveling is more difficult than a simple free so I might have a goto unravel; instead of the generic goto out; I love goto *if* you figure out a pattern for using it and stick to that. For the people who don't like goto, what is your feeling on longjmp()? From dave at horsfall.org Wed Dec 2 06:13:42 2020 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 2 Dec 2020 07:13:42 +1100 (EST) Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: <15511090.6330.1606835354160.JavaMail.root@zimbraanteil> References: <15511090.6330.1606835354160.JavaMail.root@zimbraanteil> Message-ID: On Tue, 1 Dec 2020, Jim Capp wrote: > Is it possible the elimination of the GOTO statement in the Bourne > Shellwas related to a Letter to the Editor in Communications of the ACM, > March 1968: "Go To Statement Considered Harmful," by E. Dijkstra. And then there was the story of Professor Goto (a Japanese citizen and computer bod) who complained that everyone was trying to eliminate him :-) -- Dave From robpike at gmail.com Wed Dec 2 06:13:36 2020 From: robpike at gmail.com (Rob Pike) Date: Wed, 2 Dec 2020 07:13:36 +1100 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: <202012011639.0B1GdjcD031722@freefriends.org> References: <15511090.6330.1606835354160.JavaMail.root@zimbraanteil> <202012011538.0B1FcLi5023858@freefriends.org> <202012011639.0B1GdjcD031722@freefriends.org> Message-ID: Go lets you say "Loop: for ..." and then "break Loop". -rob On Wed, Dec 2, 2020 at 3:40 AM wrote: > > On Tue, Dec 1, 2020 at 8:39 AM wrote: > > > It was recognized that goto was not necessary if one had proper control > > > structures in a language (if/else, while), and that code with no (or > > > minimal) gotos was easier to read and understand. > > Warner Losh wrote: > > This is true for simple flow control. However, when you had to break out > of > > multiple levels, or continue not the inner loop, but the middle loop, the > > use of extra booleans sure made the code less understandable than a > 'goto' > > a label that stood in for that purpose... This was something that wasn't > > well understood by language designers, and even today C and C++ neither > > have good flow control beyond the basics. Even though both break and > > continue could take an optional count without breaking old code.... > > Quite true. Modern Bourne shells let you supply a number to break and > continue to specify how many loops to break. Ada, or maybe it was one of > the Modula-X languages, let you put a label on a loop so that you could > say `continue outer' or `break outer' and not need the booleans. > > This is something that newer languages (C#, Java, Go, ...) could have > picked > up but didn't, which I think is too bad. > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Wed Dec 2 06:20:12 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 01 Dec 2020 21:20:12 +0100 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: <202012011639.0B1GdjcD031722@freefriends.org> References: <15511090.6330.1606835354160.JavaMail.root@zimbraanteil> <202012011538.0B1FcLi5023858@freefriends.org> <202012011639.0B1GdjcD031722@freefriends.org> Message-ID: <20201201202012.-40Ur%steffen@sdaoden.eu> arnold at skeeve.com wrote in <202012011639.0B1GdjcD031722 at freefriends.org>: |> On Tue, Dec 1, 2020 at 8:39 AM wrote: |>> It was recognized that goto was not necessary if one had proper control |>> structures in a language (if/else, while), and that code with no (or |>> minimal) gotos was easier to read and understand. | |Warner Losh wrote: |> This is true for simple flow control. However, when you had to break \ |> out of |> multiple levels, or continue not the inner loop, but the middle loop, the |> use of extra booleans sure made the code less understandable than \ |> a 'goto' |> a label that stood in for that purpose... This was something that wasn't |> well understood by language designers, and even today C and C++ neither |> have good flow control beyond the basics. Even though both break and |> continue could take an optional count without breaking old code.... | |Quite true. Modern Bourne shells let you supply a number to break and |continue to specify how many loops to break. Ada, or maybe it was one of |the Modula-X languages, let you put a label on a loop so that you could |say `continue outer' or `break outer' and not need the booleans. Bah, and perl could and obsoleted it, or at least jumping into blocks (not crossing initializers)! You now write code like my $ogoditisanewperl = 0; if(defined($nl = $self->begin_line)){ $self->begin_line(undef); $self->seen_endl(1); $ogoditisanewperl = 1 #goto jumpin; } while($ogoditisanewperl || ($nl = readline $self->infh)){ if(!$ogoditisanewperl){ ++${$self->__lineno}; $self->seen_endl($nl =~ s/(.*?)\s+$/$1/) } $ogoditisanewperl = 0; #jumpin: or even have to work with closures or whatever, or the worst, code duplication. |This is something that newer languages (C#, Java, Go, ...) could have \ |picked |up but didn't, which I think is too bad. Never without my goto:, and if it is only to break to error handling and/or staged destruction of local variables after initialization failures. Traumatic school impression, finding yourself locked in some PASCAL if condition, and no way to go to. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From bakul at iitbombay.org Wed Dec 2 06:39:25 2020 From: bakul at iitbombay.org (Bakul Shah) Date: Tue, 1 Dec 2020 12:39:25 -0800 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: <20201201202012.-40Ur%steffen@sdaoden.eu> References: <15511090.6330.1606835354160.JavaMail.root@zimbraanteil> <202012011538.0B1FcLi5023858@freefriends.org> <202012011639.0B1GdjcD031722@freefriends.org> <20201201202012.-40Ur%steffen@sdaoden.eu> Message-ID: <67EE6390-7E60-442B-AEEA-17951ED759A5@iitbombay.org> On Dec 1, 2020, at 12:20 PM, Steffen Nurpmeso wrote: > > Never without my goto:, and if it is only to break to error > handling and/or staged destruction of local variables after > initialization failures. Traumatic school impression, finding > yourself locked in some PASCAL if condition, and no way to go to. Pascal had goto. You can even do a non-local goto! In Go you don't need goto for the sort of thing you and McVoy talked about due to its defer statement and GC. Now granted GC may be too big of a hammer for C/C++ but a future C/C++ add defer gainfully as the defer pattern is pretty common. For example, mutex lock and unlock. But I have mixed feelings about goto vs continue/break. A nested loop with multiple continue/break can be as obscure. From cowan at ccil.org Wed Dec 2 06:49:50 2020 From: cowan at ccil.org (John Cowan) Date: Tue, 1 Dec 2020 15:49:50 -0500 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <15511090.6330.1606835354160.JavaMail.root@zimbraanteil> Message-ID: On Tue, Dec 1, 2020 at 3:14 PM Dave Horsfall wrote: > And then there was the story of Professor Goto (a Japanese citizen and > computer bod) who complained that everyone was trying to eliminate him :-) > But cheerfully so, according to Knuth. He is also known for the invention of hash consing. Knuth's article "Structured programming with goto statements" is a great discussion of all the reasons you'd want to use goto in languages with just conditionals and while loops: error exits, jumping out of nested tests, jumping out of a nest of conditionals and break/continue (both essentially kinds of static catch tags), loops iterated n-and-a-half-times (break will do this, but it's over-powered), tail recursion, "encoding boolean variables in the program counter", coroutines. There are also such things as fast linear search by putting the searched-for value at the end of the array being searched, and what boils down to Lisp macros ("allowing an optimizing compiler to express its optimizations in the source language"). On Tue, Dec 1, 2020 at 3:39 PM Bakul Shah wrote: > But I have mixed feelings about goto vs continue/break. A nested > loop with multiple continue/break can be as obscure. I think if the loops are labeled rather than the destinations, and you use "next foo" instead of "continue" and "last foo" instead of "break", it's all quite readable. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org Sir, I quite agree with you, but what are we two against so many? --George Bernard Shaw, to a man booing at the opening of _Arms and the Man_ -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Wed Dec 2 07:24:43 2020 From: crossd at gmail.com (Dan Cross) Date: Tue, 1 Dec 2020 16:24:43 -0500 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: <67EE6390-7E60-442B-AEEA-17951ED759A5@iitbombay.org> References: <15511090.6330.1606835354160.JavaMail.root@zimbraanteil> <202012011538.0B1FcLi5023858@freefriends.org> <202012011639.0B1GdjcD031722@freefriends.org> <20201201202012.-40Ur%steffen@sdaoden.eu> <67EE6390-7E60-442B-AEEA-17951ED759A5@iitbombay.org> Message-ID: On Tue, Dec 1, 2020 at 3:40 PM Bakul Shah wrote: > On Dec 1, 2020, at 12:20 PM, Steffen Nurpmeso wrote: > > Never without my goto:, and if it is only to break to error > > handling and/or staged destruction of local variables after > > initialization failures. Traumatic school impression, finding > > yourself locked in some PASCAL if condition, and no way to go to. > > Pascal had goto. Pascal also had to go. (Thanks...I'm here all week.) You can even do a non-local goto! > > In Go you don't need goto for the sort of thing you and McVoy > talked about due to its defer statement and GC. Now granted > GC may be too big of a hammer for C/C++ but a future C/C++ > add defer gainfully as the defer pattern is pretty common. > For example, mutex lock and unlock. > C++ has had something analogous for some time: destructors that run when an object goes out of scope. Scope guards to do things like close files and auto-release locks on exiting a critical section are pretty common in that world, and in general, preferable to many of the alternatives (either deeply nested conditionals or banks of labels and `goto fail1;` `goto fail2;` etc, that successively release resources on return; the latter is basically hand-rolling what the language does automatically for you, and has been the cause of at least security-related bug: apple's "goto fail" bug in their SSL implementation). There's still no easy way to break out of nested loops, though. But I have mixed feelings about goto vs continue/break. A nested > loop with multiple continue/break can be as obscure. > I submit that it's in how you write it: if the set of conditions on which one would break/continue are explicit and early in the loop body, it can be a very expressive way to write something. But like any tool, it can be abused. Along those lines, it's always been interesting to me the way that Dijkstra's statement about goto must have influenced language design. The original "GOTO Statement Considered Harmful" note was quite damning, but I wonder if it meant to be: it strikes me that the really dangerous thing about "goto" isn't its mere existence or even its use, but rather, it's unconstrained use when better alternatives exist in the language. As one can observe in well-written C code, judicious use of `goto` can be quite elegant in comparison to the alternative. I've often wondered whether language designers, mindful of the pitfalls of `goto`, eventually took the most useful patterns of its usage and extracted them to stand on their own. Early returns from functions are an obvious example, but so are `break` and `continue` and one might argue exceptions fall into the same category. It strikes me that as we gain ever greater experience with languages, we find more and more examples of things one routinely does using a blunt instrument like goto, and we refine those to first-class features of the language. I think it's also illustrative of how social pressure can influence one to avoid "dangerous" patterns in favor of these language features. C isn't inherently more dangerous because it has a goto statement and labels; most of the time, one doesn't bother to use goto because alternatives exist that are more natural and fill the same role (continue, break, return, etc). - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Wed Dec 2 09:44:31 2020 From: cowan at ccil.org (John Cowan) Date: Tue, 1 Dec 2020 18:44:31 -0500 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <15511090.6330.1606835354160.JavaMail.root@zimbraanteil> <202012011538.0B1FcLi5023858@freefriends.org> <202012011639.0B1GdjcD031722@freefriends.org> <20201201202012.-40Ur%steffen@sdaoden.eu> <67EE6390-7E60-442B-AEEA-17951ED759A5@iitbombay.org> Message-ID: On Tue, Dec 1, 2020 at 3:40 PM Bakul Shah wrote: Along those lines, it's always been interesting to me the way that > Dijkstra's statement about goto must have influenced language design. The > original "GOTO Statement Considered Harmful" note was quite damning, but I > wonder if it meant to be: it strikes me that the really dangerous thing > about "goto" isn't its mere existence or even its use, but rather, it's > unconstrained use when better alternatives exist in the language. As one > can observe in well-written C code, judicious use of `goto` can be quite > elegant in comparison to the alternative. > D-1stra originally sent "Go to [...]" to CACM as a paper entitled "A Case Against The Go To Statement". But the editor, who was Niklaus Wirth, thought it important to publish it quickly, so he turned it into a letter to the editor and retitled it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Wed Dec 2 10:31:27 2020 From: ggm at algebras.org (George Michaelson) Date: Wed, 2 Dec 2020 10:31:27 +1000 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: <20201201031306.C1E6943F88@lignose.oclsc.org> References: <20201201031306.C1E6943F88@lignose.oclsc.org> Message-ID: I don't normally like referring to "fight club" because its a crap movie. But "we don't talk about fight club" is a really useful rule. If you name call people on a list too much, they don't want to be on the list. It's not a place to collect gold stamps, or rare birds. I suspect I'd pass half the members of the list on the street and fail to recognize them. I very much hope this is reciprocated. cheers -G From athornton at gmail.com Wed Dec 2 11:06:16 2020 From: athornton at gmail.com (Adam Thornton) Date: Tue, 1 Dec 2020 18:06:16 -0700 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <20201201031306.C1E6943F88@lignose.oclsc.org> Message-ID: Pretty sure I would pass ALL the members of the list on the street and fail to recognize them. Yes, even the famous ones. Also, "Fight Club" is not a crap movie and I will fight you over that. Adam On Tue, Dec 1, 2020 at 5:32 PM George Michaelson wrote: > I don't normally like referring to "fight club" because its a crap > movie. But "we don't talk about fight club" is a really useful rule. > > If you name call people on a list too much, they don't want to be on > the list. It's not a place to collect gold stamps, or rare birds. > > I suspect I'd pass half the members of the list on the street and fail > to recognize them. I very much hope this is reciprocated. > > cheers > > -G > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Dec 2 17:08:08 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 02 Dec 2020 00:08:08 -0700 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <15511090.6330.1606835354160.JavaMail.root@zimbraanteil> <202012011538.0B1FcLi5023858@freefriends.org> <202012011639.0B1GdjcD031722@freefriends.org> Message-ID: <202012020708.0B2788CG010176@freefriends.org> If I knew that I forgot it (obviously). Thanks for letting me know. Yet another reason to move to Go. Has it been there since Day 1? Just wondering. Thanks, Arnold Rob Pike wrote: > Go lets you say "Loop: for ..." and then "break Loop". > > -rob From robpike at gmail.com Wed Dec 2 17:29:42 2020 From: robpike at gmail.com (Rob Pike) Date: Wed, 2 Dec 2020 18:29:42 +1100 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: <202012020708.0B2788CG010176@freefriends.org> References: <15511090.6330.1606835354160.JavaMail.root@zimbraanteil> <202012011538.0B1FcLi5023858@freefriends.org> <202012011639.0B1GdjcD031722@freefriends.org> <202012020708.0B2788CG010176@freefriends.org> Message-ID: Yes. -rob On Wed, Dec 2, 2020 at 6:08 PM wrote: > If I knew that I forgot it (obviously). Thanks for letting me know. > Yet another reason to move to Go. > > Has it been there since Day 1? Just wondering. > > Thanks, > > Arnold > > Rob Pike wrote: > > > Go lets you say "Loop: for ..." and then "break Loop". > > > > -rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Thu Dec 3 03:02:27 2020 From: cowan at ccil.org (John Cowan) Date: Wed, 2 Dec 2020 12:02:27 -0500 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <20201201031306.C1E6943F88@lignose.oclsc.org> Message-ID: On Tue, Dec 1, 2020 at 8:06 PM Adam Thornton wrote: Pretty sure I would pass ALL the members of the list on the street and fail > to recognize them. Yes, even the famous ones. > I can pass anyone on the street and fail to recognize them (google "prosopagnosia" or "face blindness"). > Also, "Fight Club" is not a crap movie and I will fight you over that. > The first rule of Fish Club is that whales are not fish. The second rule of Fish Club is that lungfish are not fish either. The first rule of Linguist Club is to explain who belongs to Linguist Club. The first rule of Tautology Club is the first rule of Tautology Club. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org Sir, I quite agree with you, but what are we two against so many? --George Bernard Shaw, to a man booing at the opening of _Arms and the Man_ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmhanson at eschatologist.net Fri Dec 4 04:40:52 2020 From: cmhanson at eschatologist.net (Chris Hanson) Date: Thu, 3 Dec 2020 10:40:52 -0800 Subject: [TUHS] Apple IIe Unix? In-Reply-To: References: Message-ID: The ads for Manx Aztec C for the Apple II described providing a UNIX-like programming environment. You might find that useful. There’s a bunch of detail online here: http://www.aztecmuseum.ca/intro.htm I think it may have even provided pipelines and such (albeit with sequential rather than simultaneous execution). -- Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.douglas.mcilroy at dartmouth.edu Fri Dec 4 06:31:14 2020 From: m.douglas.mcilroy at dartmouth.edu (M Douglas McIlroy) Date: Thu, 3 Dec 2020 15:31:14 -0500 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: Message-ID: There's a back story. The paper appears in the proceedings of a conference held in London in 1973, a few months after the advent of pipes. While preparing the presentation, Ken was inspired to invent and install the pipe operator. His talk wouldn't have been nearly as compelling had it been expressed in the original pipeline syntax (for which I take the blame). References to eqn (v5), bc (v6), and ratfor (v7) obviously postdate the London conference. Ken must have edited--or re-created--the transcript for the proceedings sometime after v6 (May, 1975). Bibliographic citations are missing. Can they be resurrected? Reference 137, about Unix itself, probably refers to a presentation by Ken and Dennis at SOSP in January1973. Alas, only an abstract of the talk appears in the conference proceedings. But the abstract does contain the potent and often-repeated sentence, "It offers a number of features seldom found even in larger operating systems, including ... inter-process IO ..." The talk--in Yorktown Heights--was memorable, and so was a ride to the same place in Ken's 'vette. (I can't recall whether the two happened on the same occasion.) Given that the talk at SOSP preceded the talk in London, and that the Unix manual was widely distributed by (1976) when the revised London talk was printed, the claim that "The Unix command language" was the first publication of Unix seems hyperbolic. In no way, though, does this detract from the inherent interest of the paper. Doug From nikke.karlsson at gmail.com Fri Dec 4 06:37:17 2020 From: nikke.karlsson at gmail.com (Niklas Karlsson) Date: Thu, 3 Dec 2020 21:37:17 +0100 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: Message-ID: Den tors 3 dec. 2020 kl 21:32 skrev M Douglas McIlroy < m.douglas.mcilroy at dartmouth.edu>: > There's a back story. The paper appears in the proceedings of a > conference held in London in 1973, a few months after the advent of > pipes. While preparing the presentation, Ken was inspired to invent > and install the pipe operator. His talk wouldn't have been nearly as > compelling had it been expressed in the original pipeline syntax (for > which I take the blame). > Now I'm curious. Is there anywhere I can read about the original pipeline syntax? I tried searching a bit, but the only mention that was even vaguely informative only stated that > was involved. Thanks! Niklas -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Dec 4 06:43:01 2020 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 3 Dec 2020 12:43:01 -0800 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: Message-ID: <20201203204301.GW19746@mcvoy.com> On Thu, Dec 03, 2020 at 09:37:17PM +0100, Niklas Karlsson wrote: > Den tors 3 dec. 2020 kl 21:32 skrev M Douglas McIlroy < > m.douglas.mcilroy at dartmouth.edu>: > > > There's a back story. The paper appears in the proceedings of a > > conference held in London in 1973, a few months after the advent of > > pipes. While preparing the presentation, Ken was inspired to invent > > and install the pipe operator. His talk wouldn't have been nearly as > > compelling had it been expressed in the original pipeline syntax (for > > which I take the blame). > > > > Now I'm curious. Is there anywhere I can read about the original pipeline > syntax? I tried searching a bit, but the only mention that was even vaguely > informative only stated that > was involved. Wasn't there a version that was cat whatever ^ wc -l ? From m.douglas.mcilroy at dartmouth.edu Fri Dec 4 06:51:24 2020 From: m.douglas.mcilroy at dartmouth.edu (M Douglas McIlroy) Date: Thu, 3 Dec 2020 15:51:24 -0500 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: Message-ID: https://archive.org/details/a_research_unix_reader pp 29-30 On Thu, Dec 3, 2020 at 3:37 PM Niklas Karlsson wrote: > > Den tors 3 dec. 2020 kl 21:32 skrev M Douglas McIlroy : >> >> There's a back story. The paper appears in the proceedings of a >> conference held in London in 1973, a few months after the advent of >> pipes. While preparing the presentation, Ken was inspired to invent >> and install the pipe operator. His talk wouldn't have been nearly as >> compelling had it been expressed in the original pipeline syntax (for >> which I take the blame). > > > Now I'm curious. Is there anywhere I can read about the original pipeline syntax? I tried searching a bit, but the only mention that was even vaguely informative only stated that > was involved. > > Thanks! > Niklas From bdwalton at gmail.com Fri Dec 4 07:01:00 2020 From: bdwalton at gmail.com (Ben Walton) Date: Thu, 3 Dec 2020 21:01:00 +0000 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: <20201203204301.GW19746@mcvoy.com> References: <20201203204301.GW19746@mcvoy.com> Message-ID: On Thu 3 Dec 2020, 20:43 Larry McVoy, wrote: > On Thu, Dec 03, 2020 at 09:37:17PM +0100, Niklas Karlsson wrote: > > Den tors 3 dec. 2020 kl 21:32 skrev M Douglas McIlroy < > > m.douglas.mcilroy at dartmouth.edu>: > > > > > There's a back story. The paper appears in the proceedings of a > > > conference held in London in 1973, a few months after the advent of > > > pipes. While preparing the presentation, Ken was inspired to invent > > > and install the pipe operator. His talk wouldn't have been nearly as > > > compelling had it been expressed in the original pipeline syntax (for > > > which I take the blame). > > > > > > > Now I'm curious. Is there anywhere I can read about the original pipeline > > syntax? I tried searching a bit, but the only mention that was even > vaguely > > informative only stated that > was involved. > > Wasn't there a version that was > > cat whatever ^ wc -l > > ? > Yes, that's it. And you'll still find[1] that /bin/sh on (at least?) Solaris honors that syntax. That's one reason why the git test suite fails on Solaris without being pushed to use a modern shell implementation. Thanks -Ben [1] At least up to Solaris 10. I've not used newer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at inputplus.co.uk Fri Dec 4 06:56:40 2020 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Thu, 03 Dec 2020 20:56:40 +0000 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: <20201203204301.GW19746@mcvoy.com> References: <20201203204301.GW19746@mcvoy.com> Message-ID: <20201203205640.E9CEB22181@orac.inputplus.co.uk> Hi Larry, > Wasn't there a version that was > > cat whatever ^ wc -l It existed for quite a while in Bourne's shell even when | came along and was useful when the keyboard didn't have a | keycap or, more likely, when it was a modern machine with the capability of mapping keys which had a poor mapping with no | available. -- Cheers, Ralph. From clemc at ccc.com Fri Dec 4 07:12:22 2020 From: clemc at ccc.com (Clem Cole) Date: Thu, 3 Dec 2020 16:12:22 -0500 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: <20201203204301.GW19746@mcvoy.com> References: <20201203204301.GW19746@mcvoy.com> Message-ID: Yup early shell's equated ^ and | The problem was while the Model - 33, post 1965 could print a vertical bar, as note 2 of page three of teletypes document: "33 Keyboard" General Description and Principles of Operations" ISS 4, Section 574-121-100TC (Issue 4, June 1974), the keyboard could not generate it. On Thu, Dec 3, 2020 at 3:43 PM Larry McVoy wrote: > On Thu, Dec 03, 2020 at 09:37:17PM +0100, Niklas Karlsson wrote: > > Den tors 3 dec. 2020 kl 21:32 skrev M Douglas McIlroy < > > m.douglas.mcilroy at dartmouth.edu>: > > > > > There's a back story. The paper appears in the proceedings of a > > > conference held in London in 1973, a few months after the advent of > > > pipes. While preparing the presentation, Ken was inspired to invent > > > and install the pipe operator. His talk wouldn't have been nearly as > > > compelling had it been expressed in the original pipeline syntax (for > > > which I take the blame). > > > > > > > Now I'm curious. Is there anywhere I can read about the original pipeline > > syntax? I tried searching a bit, but the only mention that was even > vaguely > > informative only stated that > was involved. > > Wasn't there a version that was > > cat whatever ^ wc -l > > ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Fri Dec 4 10:29:38 2020 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 4 Dec 2020 11:29:38 +1100 (EST) Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: <20201203204301.GW19746@mcvoy.com> References: <20201203204301.GW19746@mcvoy.com> Message-ID: On Thu, 3 Dec 2020, Larry McVoy wrote: > Wasn't there a version that was > > cat whatever ^ wc -l Sort of pipe-related, but one thing that really gets my goat is the inefficient redundancy in "cat file | process" when "process < file" will suffice (and I'll bet that I'm not alone). And yes, "^" preceded "|" for reasons discussed later in this thread. -- Dave From robpike at gmail.com Fri Dec 4 10:43:52 2020 From: robpike at gmail.com (Rob Pike) Date: Fri, 4 Dec 2020 11:43:52 +1100 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <20201203204301.GW19746@mcvoy.com> Message-ID: I've long been fascinated by the prevalence of cat file | process and think of it as a sort of triumph of the model. Pipes are more natural than redirection as a human interface. -rob On Fri, Dec 4, 2020 at 11:30 AM Dave Horsfall wrote: > On Thu, 3 Dec 2020, Larry McVoy wrote: > > > Wasn't there a version that was > > > > cat whatever ^ wc -l > > Sort of pipe-related, but one thing that really gets my goat is the > inefficient redundancy in "cat file | process" when "process < file" will > suffice (and I'll bet that I'm not alone). > > And yes, "^" preceded "|" for reasons discussed later in this thread. > > -- Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Fri Dec 4 10:45:19 2020 From: ggm at algebras.org (George Michaelson) Date: Fri, 4 Dec 2020 10:45:19 +1000 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <20201203204301.GW19746@mcvoy.com> Message-ID: I also get this, but there is a part of this which is about the history of your command stream as a history of thinking. cat file (sigh) cat file | more not more file. because you are heading to cat file | cut -d, -f1,2 | real-job yes, the cat is redundant. but syntactically it is like (a b) + vs plus(a,b) its not the functional order of the atoms for execution, its how you "pronounce" the work you are doing inside your head.. expressed through your fingers. The cost of the cat is really not big. the cost of re-framing your command to cmd < thing is sometimes higher in brain cost. Brains are expensive. On Fri, Dec 4, 2020 at 10:30 AM Dave Horsfall wrote: > > On Thu, 3 Dec 2020, Larry McVoy wrote: > > > Wasn't there a version that was > > > > cat whatever ^ wc -l > > Sort of pipe-related, but one thing that really gets my goat is the > inefficient redundancy in "cat file | process" when "process < file" will > suffice (and I'll bet that I'm not alone). > > And yes, "^" preceded "|" for reasons discussed later in this thread. > > -- Dave From lm at mcvoy.com Fri Dec 4 10:48:59 2020 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 3 Dec 2020 16:48:59 -0800 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <20201203204301.GW19746@mcvoy.com> Message-ID: <20201204004859.GZ19746@mcvoy.com> I should have done cat file file2 file3 ^ wc -l since the redirect works with only one file. On Fri, Dec 04, 2020 at 11:43:52AM +1100, Rob Pike wrote: > I've long been fascinated by the prevalence of > > cat file | process > > and think of it as a sort of triumph of the model. Pipes are more natural > than redirection as a human interface. > > -rob > > > On Fri, Dec 4, 2020 at 11:30 AM Dave Horsfall wrote: > > > On Thu, 3 Dec 2020, Larry McVoy wrote: > > > > > Wasn't there a version that was > > > > > > cat whatever ^ wc -l > > > > Sort of pipe-related, but one thing that really gets my goat is the > > inefficient redundancy in "cat file | process" when "process < file" will > > suffice (and I'll bet that I'm not alone). > > > > And yes, "^" preceded "|" for reasons discussed later in this thread. > > > > -- Dave > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From bakul at iitbombay.org Fri Dec 4 10:51:30 2020 From: bakul at iitbombay.org (Bakul Shah) Date: Thu, 3 Dec 2020 16:51:30 -0800 Subject: [TUHS] The origin of Goto considered harmful? Message-ID: <30EBC7A6-4527-4FDC-9FCB-B262DBA4F893@iitbombay.org> Last night I stumbled upon this speech by Doug McIlroy at Dijkstra's retirement banquet @ UT Austin where he tells the story of his first encounter with EWD and the origins of programming without goto.... Given that we recently had a discussion on "Goto considered harmful", you all may enjoy it. Make sure you watch the start of part 10 as well as that is where the story ends. https://youtu.be/5OUPBwrufKA?list=PL328C7EFFC1F41674&t=326 From bakul at iitbombay.org Fri Dec 4 11:10:51 2020 From: bakul at iitbombay.org (Bakul Shah) Date: Thu, 3 Dec 2020 17:10:51 -0800 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <20201203204301.GW19746@mcvoy.com> Message-ID: <040A3300-994D-4268-B22B-9F99B579F999@iitbombay.org> On Dec 3, 2020, at 4:29 PM, Dave Horsfall wrote: > > On Thu, 3 Dec 2020, Larry McVoy wrote: > >> Wasn't there a version that was >> >> cat whatever ^ wc -l > > Sort of pipe-related, but one thing that really gets my goat is the inefficient redundancy in "cat file | process" when "process < file" will suffice (and I'll bet that I'm not alone). Checking command history in zsh: $ h 1-|wc -l; h 1-|grep '<' | wc -l; h 1-|grep '>' | wc -l; h 1-|grep '|'|wc -l 10009 125 225 878 So it appears I used < ~1%, > ~2% and | ~9% of the command lines! I bet others will something similar. From ggm at algebras.org Fri Dec 4 11:17:45 2020 From: ggm at algebras.org (George Michaelson) Date: Fri, 4 Dec 2020 11:17:45 +1000 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: <040A3300-994D-4268-B22B-9F99B579F999@iitbombay.org> References: <20201203204301.GW19746@mcvoy.com> <040A3300-994D-4268-B22B-9F99B579F999@iitbombay.org> Message-ID: ggm at ggm-802382 ~ % h 1-|wc -l; h 1-|grep '<' | wc -l; h 1-|grep '>' | wc -l; h 1-|grep '|'|wc -l 1005 34 14 91 ggm at ggm-802382 ~ % On Fri, Dec 4, 2020 at 11:11 AM Bakul Shah wrote: > > On Dec 3, 2020, at 4:29 PM, Dave Horsfall wrote: > > > > On Thu, 3 Dec 2020, Larry McVoy wrote: > > > >> Wasn't there a version that was > >> > >> cat whatever ^ wc -l > > > > Sort of pipe-related, but one thing that really gets my goat is the inefficient redundancy in "cat file | process" when "process < file" will suffice (and I'll bet that I'm not alone). > > Checking command history in zsh: > $ h 1-|wc -l; h 1-|grep '<' | wc -l; h 1-|grep '>' | wc -l; h 1-|grep '|'|wc -l > 10009 > 125 > 225 > 878 > > So it appears I used < ~1%, > ~2% and | ~9% of the command lines! > I bet others will something similar. From crossd at gmail.com Fri Dec 4 11:25:06 2020 From: crossd at gmail.com (Dan Cross) Date: Thu, 3 Dec 2020 20:25:06 -0500 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <20201203204301.GW19746@mcvoy.com> Message-ID: On Thu, Dec 3, 2020 at 7:44 PM Rob Pike wrote: > I've long been fascinated by the prevalence of > > cat file | process > > and think of it as a sort of triumph of the model. Pipes are more natural > than redirection as a human interface. > This has always struck me as particularly elegant in scripts. Consider: cat "$@" | whatever (Or you may prefer `cat $* | whatever`) Now one's script can take any number of file arguments or stdin, even if the filter does not. - Dan C. On Fri, Dec 4, 2020 at 11:30 AM Dave Horsfall wrote: > >> On Thu, 3 Dec 2020, Larry McVoy wrote: >> >> > Wasn't there a version that was >> > >> > cat whatever ^ wc -l >> >> Sort of pipe-related, but one thing that really gets my goat is the >> inefficient redundancy in "cat file | process" when "process < file" will >> suffice (and I'll bet that I'm not alone). >> >> And yes, "^" preceded "|" for reasons discussed later in this thread. >> >> -- Dave >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Dec 4 13:35:02 2020 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 3 Dec 2020 19:35:02 -0800 Subject: [TUHS] The origin of Goto considered harmful? In-Reply-To: <30EBC7A6-4527-4FDC-9FCB-B262DBA4F893@iitbombay.org> References: <30EBC7A6-4527-4FDC-9FCB-B262DBA4F893@iitbombay.org> Message-ID: <20201204033502.GA19746@mcvoy.com> I have gone down the rabbit hole of this and I can not thank you enough. On Thu, Dec 03, 2020 at 04:51:30PM -0800, Bakul Shah wrote: > Last night I stumbled upon this speech by Doug McIlroy at Dijkstra's retirement banquet @ UT Austin where he tells the story of his first encounter with EWD and the origins of programming without goto.... Given that we recently had a discussion on "Goto considered harmful", you all may enjoy it. Make sure you watch the start of part 10 as well as that is where the story ends. > > https://youtu.be/5OUPBwrufKA?list=PL328C7EFFC1F41674&t=326 -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From meillo at marmaro.de Fri Dec 4 17:04:21 2020 From: meillo at marmaro.de (markus schnalke) Date: Fri, 04 Dec 2020 08:04:21 +0100 Subject: [TUHS] Command name of the B compiler; One letter command names Message-ID: <1kl58f-5CH-00@marmaro.de> Hoi, I'm wondering what the name of the B compiler was. Doug's ``Unix Reader'' lists: 1 2 3 4 5 6 7 8 9 + + + . . . . . . b compile b program . . . . . + + + + bc arbitrary-precision arithmetic language Via Wikipedia I found a scan of the ``Users' Reference to B'', a technical memorandum by Ken, dated 1972-01-07 (which is between the releases of the 1st and 2nd Edition). https://web.archive.org/web/20150317033259/https://www.bell-labs.com/usr/dmr/www/kbman.pdf There on page 25: 10.0 Usage Currently on UNIX, there is no B command. The B compiler phases must be executed piecemeal. The first phase turns a B source program into an intermediate language. /etc/bc source interm The next phase turns the intermediate language into assembler source, at which time the intermediate language can be removed. /etc/ba interm asource rm interm The next phase assembles the assembler source into the object tile a.out. After this the a.out file can be renamed and the assembler source file can be removed. as asource mv a.out object rm asource The last phase loads the various object files with the necessary libraries in the desired order. ld object /etc/brtl -lb /etc/bilib /etc/brt2 Now a.out contains the completely bound and loaded program and can be executed. a.out A canned sequence of shell commands exists invoked as follows: sh /usr/b/rc x It will compile, convert, assemble and load the file x.b into the executable file a.out. It lists /etc/bc, as a command to convert into the intermediate language, and /etc/ba, to convert the intermediate language into assembler source, but lists no `b' command. The wrapper script is /usr/b/rc. Can someone clarify? I came to this question because I was looking for one letter commands. I always thought them to be a reserved namespace for the user ... Any background on that topic is appreciated as well. ;-) meillo From arnold at skeeve.com Fri Dec 4 19:27:46 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 04 Dec 2020 02:27:46 -0700 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <20201203204301.GW19746@mcvoy.com> Message-ID: <202012040927.0B49Rkx6019895@freefriends.org> Dan Cross wrote: > This has always struck me as particularly elegant in scripts. Consider: > > cat "$@" | whatever > > (Or you may prefer `cat $* | whatever`) > > Now one's script can take any number of file arguments or stdin, even if > the filter does not. I think Dan has hit the heart of the matter. People are used to using cat for multiple files to start pumping data down a pipeline, so they continue to do so even when there's only one file. Arnold From akosela at andykosela.com Fri Dec 4 21:33:43 2020 From: akosela at andykosela.com (Andy Kosela) Date: Fri, 4 Dec 2020 12:33:43 +0100 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: <202012040927.0B49Rkx6019895@freefriends.org> References: <20201203204301.GW19746@mcvoy.com> <202012040927.0B49Rkx6019895@freefriends.org> Message-ID: On 12/4/20, arnold at skeeve.com wrote: > Dan Cross wrote: > >> This has always struck me as particularly elegant in scripts. Consider: >> >> cat "$@" | whatever >> >> (Or you may prefer `cat $* | whatever`) >> >> Now one's script can take any number of file arguments or stdin, even if >> the filter does not. > > I think Dan has hit the heart of the matter. People are used to using > cat for multiple files to start pumping data down a pipeline, so they > continue to do so even when there's only one file. > The classic example is: $ cat file | grep foo instead of the simpler: $ grep foo file It appears cat(1) and pipe(7) are deeply ingrained in people's brains. --Andy From coppero1237 at gmail.com Fri Dec 4 23:14:52 2020 From: coppero1237 at gmail.com (Tyler Adams) Date: Fri, 4 Dec 2020 15:14:52 +0200 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <20201203204301.GW19746@mcvoy.com> <202012040927.0B49Rkx6019895@freefriends.org> Message-ID: I find cat file | grep foo simpler because it reads Left to Right. Tyler On Fri, Dec 4, 2020 at 1:34 PM Andy Kosela wrote: > On 12/4/20, arnold at skeeve.com wrote: > > Dan Cross wrote: > > > >> This has always struck me as particularly elegant in scripts. Consider: > >> > >> cat "$@" | whatever > >> > >> (Or you may prefer `cat $* | whatever`) > >> > >> Now one's script can take any number of file arguments or stdin, even if > >> the filter does not. > > > > I think Dan has hit the heart of the matter. People are used to using > > cat for multiple files to start pumping data down a pipeline, so they > > continue to do so even when there's only one file. > > > > The classic example is: > > $ cat file | grep foo > > instead of the simpler: > > $ grep foo file > > It appears cat(1) and pipe(7) are deeply ingrained in people's brains. > > --Andy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikke.karlsson at gmail.com Fri Dec 4 23:17:43 2020 From: nikke.karlsson at gmail.com (Niklas Karlsson) Date: Fri, 4 Dec 2020 14:17:43 +0100 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <20201203204301.GW19746@mcvoy.com> <202012040927.0B49Rkx6019895@freefriends.org> Message-ID: < file grep foo works. Niklas Den fre 4 dec. 2020 kl 14:16 skrev Tyler Adams : > I find cat file | grep foo simpler because it reads Left to Right. > > Tyler > > > On Fri, Dec 4, 2020 at 1:34 PM Andy Kosela wrote: > >> On 12/4/20, arnold at skeeve.com wrote: >> > Dan Cross wrote: >> > >> >> This has always struck me as particularly elegant in scripts. Consider: >> >> >> >> cat "$@" | whatever >> >> >> >> (Or you may prefer `cat $* | whatever`) >> >> >> >> Now one's script can take any number of file arguments or stdin, even >> if >> >> the filter does not. >> > >> > I think Dan has hit the heart of the matter. People are used to using >> > cat for multiple files to start pumping data down a pipeline, so they >> > continue to do so even when there's only one file. >> > >> >> The classic example is: >> >> $ cat file | grep foo >> >> instead of the simpler: >> >> $ grep foo file >> >> It appears cat(1) and pipe(7) are deeply ingrained in people's brains. >> >> --Andy >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coppero1237 at gmail.com Fri Dec 4 23:22:56 2020 From: coppero1237 at gmail.com (Tyler Adams) Date: Fri, 4 Dec 2020 15:22:56 +0200 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <20201203204301.GW19746@mcvoy.com> <202012040927.0B49Rkx6019895@freefriends.org> Message-ID: Not always $ cat a | while read line; do echo $line; done #!/usr/bin/env bash PUPPETEER_PRODUCT=firefox npm install -g md-to-pdf $ < a while read line; do echo $line; done -bash: syntax error near unexpected token `do' Tyler On Fri, Dec 4, 2020 at 3:17 PM Niklas Karlsson wrote: > < file grep foo works. > > Niklas > > Den fre 4 dec. 2020 kl 14:16 skrev Tyler Adams : > >> I find cat file | grep foo simpler because it reads Left to Right. >> >> Tyler >> >> >> On Fri, Dec 4, 2020 at 1:34 PM Andy Kosela >> wrote: >> >>> On 12/4/20, arnold at skeeve.com wrote: >>> > Dan Cross wrote: >>> > >>> >> This has always struck me as particularly elegant in scripts. >>> Consider: >>> >> >>> >> cat "$@" | whatever >>> >> >>> >> (Or you may prefer `cat $* | whatever`) >>> >> >>> >> Now one's script can take any number of file arguments or stdin, even >>> if >>> >> the filter does not. >>> > >>> > I think Dan has hit the heart of the matter. People are used to using >>> > cat for multiple files to start pumping data down a pipeline, so they >>> > continue to do so even when there's only one file. >>> > >>> >>> The classic example is: >>> >>> $ cat file | grep foo >>> >>> instead of the simpler: >>> >>> $ grep foo file >>> >>> It appears cat(1) and pipe(7) are deeply ingrained in people's brains. >>> >>> --Andy >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikke.karlsson at gmail.com Fri Dec 4 23:25:53 2020 From: nikke.karlsson at gmail.com (Niklas Karlsson) Date: Fri, 4 Dec 2020 14:25:53 +0100 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <20201203204301.GW19746@mcvoy.com> <202012040927.0B49Rkx6019895@freefriends.org> Message-ID: Fair enough, and I guess it gets messy trying to remember all of the odd exceptions. Niklas Den fre 4 dec. 2020 kl 14:23 skrev Tyler Adams : > Not always > > $ cat a | while read line; do echo $line; done > #!/usr/bin/env bash > > PUPPETEER_PRODUCT=firefox npm install -g md-to-pdf > > $ < a while read line; do echo $line; done > -bash: syntax error near unexpected token `do' > > > Tyler > > > On Fri, Dec 4, 2020 at 3:17 PM Niklas Karlsson > wrote: > >> < file grep foo works. >> >> Niklas >> >> Den fre 4 dec. 2020 kl 14:16 skrev Tyler Adams : >> >>> I find cat file | grep foo simpler because it reads Left to Right. >>> >>> Tyler >>> >>> >>> On Fri, Dec 4, 2020 at 1:34 PM Andy Kosela >>> wrote: >>> >>>> On 12/4/20, arnold at skeeve.com wrote: >>>> > Dan Cross wrote: >>>> > >>>> >> This has always struck me as particularly elegant in scripts. >>>> Consider: >>>> >> >>>> >> cat "$@" | whatever >>>> >> >>>> >> (Or you may prefer `cat $* | whatever`) >>>> >> >>>> >> Now one's script can take any number of file arguments or stdin, >>>> even if >>>> >> the filter does not. >>>> > >>>> > I think Dan has hit the heart of the matter. People are used to using >>>> > cat for multiple files to start pumping data down a pipeline, so they >>>> > continue to do so even when there's only one file. >>>> > >>>> >>>> The classic example is: >>>> >>>> $ cat file | grep foo >>>> >>>> instead of the simpler: >>>> >>>> $ grep foo file >>>> >>>> It appears cat(1) and pipe(7) are deeply ingrained in people's brains. >>>> >>>> --Andy >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Sat Dec 5 01:30:46 2020 From: cowan at ccil.org (John Cowan) Date: Fri, 4 Dec 2020 10:30:46 -0500 Subject: [TUHS] Command name of the B compiler; One letter command names In-Reply-To: <1kl58f-5CH-00@marmaro.de> References: <1kl58f-5CH-00@marmaro.de> Message-ID: On Fri, Dec 4, 2020 at 2:12 AM markus schnalke wrote: > Hoi, > coi :-) > Currently on UNIX, there is no B command. A script named "B" (note capital letter) was written at some point that performed the explicit steps shown in the B manual. This was evidently renamed to "b" at some point. "All is in flux." I came to this question because I was looking for one letter > commands. I always thought them to be a reserved namespace for the > user ... > By no means, at least not by now. "x" is the name of the raw X11 binary, and "w" is a variant of "who" that displays the idle time (similar to "finger") and the last command executed. The J and K language interpreters from the APL dharma line (and consequently oriented toward terseness) are executed as "J" and "k" respectively. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org There is / One art / No more / No less To do / All things / With art- / -Lessness --Piet Hein -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Sat Dec 5 02:02:22 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 04 Dec 2020 17:02:22 +0100 Subject: [TUHS] The origin of Goto considered harmful? In-Reply-To: <30EBC7A6-4527-4FDC-9FCB-B262DBA4F893@iitbombay.org> References: <30EBC7A6-4527-4FDC-9FCB-B262DBA4F893@iitbombay.org> Message-ID: <20201204160222.aPNy3%steffen@sdaoden.eu> Bakul Shah wrote in <30EBC7A6-4527-4FDC-9FCB-B262DBA4F893 at iitbombay.org>: |Last night I stumbled upon this speech by Doug McIlroy at Dijkstra's \ |retirement banquet @ UT Austin where he tells the story of his first \ |encounter with EWD and the origins of programming without goto.... \ |Given that we recently had a discussion on "Goto considered harmful", \ |you all may enjoy it. Make sure you watch the start of part 10 as well \ |as that is where the story ends. | |https://youtu.be/5OUPBwrufKA?list=PL328C7EFFC1F41674&t=326 An intracardiac heart injection of adrenaline! (Later medical studies seem to contradict the original thinking of its usefulness i have heard (a bit).) #?141|kent:plan9port.git$ git grep goto master|wc -l ... echo 2MzQ1Mwo= | openssl base64 -d (Obscured for the highly sensitive (the "h" in "tuhs") among the audience.) --End of <30EBC7A6-4527-4FDC-9FCB-B262DBA4F893 at iitbombay.org> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From rich.salz at gmail.com Sat Dec 5 08:00:16 2020 From: rich.salz at gmail.com (Richard Salz) Date: Fri, 4 Dec 2020 17:00:16 -0500 Subject: [TUHS] Command name of the B compiler; One letter command names In-Reply-To: References: <1kl58f-5CH-00@marmaro.de> Message-ID: And of course there's the "B" command to open file(s) in an existing sam instance. I am glad there aren't many, since that leaves them for users; I have several single-letter commands: ; grep 'fn . {' .rcrc | wc -l 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Sat Dec 5 08:43:00 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 04 Dec 2020 23:43:00 +0100 Subject: [TUHS] The origin of Goto considered harmful? In-Reply-To: <20201204160222.aPNy3%steffen@sdaoden.eu> References: <30EBC7A6-4527-4FDC-9FCB-B262DBA4F893@iitbombay.org> <20201204160222.aPNy3%steffen@sdaoden.eu> Message-ID: <20201204224300.SwM1C%steffen@sdaoden.eu> Steffen Nurpmeso wrote in <20201204160222.aPNy3%steffen at sdaoden.eu>: |Bakul Shah wrote in | <30EBC7A6-4527-4FDC-9FCB-B262DBA4F893 at iitbombay.org>: ||Last night I stumbled upon this speech by Doug McIlroy at Dijkstra's \ ||retirement banquet @ UT Austin where he tells the story of his first \ ||encounter with EWD and the origins of programming without goto.... \ ||Given that we recently had a discussion on "Goto considered harmful", \ ||you all may enjoy it. Make sure you watch the start of part 10 as well \ ||as that is where the story ends. || ||https://youtu.be/5OUPBwrufKA?list=PL328C7EFFC1F41674&t=326 ... |its usefulness i have heard (a bit).) | | #?141|kent:plan9port.git$ git grep goto master|wc -l |... | echo 2MzQ1Mwo= | openssl base64 -d Where that 2 comes from i do not know, it should have been MzQ1Mwo=. Ciao, and a nice weekend i wish from Germany, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From rminnich at gmail.com Wed Dec 9 04:11:00 2020 From: rminnich at gmail.com (ron minnich) Date: Tue, 8 Dec 2020 10:11:00 -0800 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? Message-ID: When I got into Unix in 1976 cron and at were both there. I got to wondering for no particular reason which came first -- I had always assumed cron, but ...? Anyone know? From mah at mhorton.net Wed Dec 9 04:51:05 2020 From: mah at mhorton.net (Mary Ann Horton) Date: Tue, 8 Dec 2020 10:51:05 -0800 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: References: Message-ID: My V6 manual has cron(VIII) - documentation of /usr/lib/crontab - but no mention of at. This is consistent with my recollection - I first saw at in V7.     Mary Ann On 12/8/20 10:11 AM, ron minnich wrote: > When I got into Unix in 1976 cron and at were both there. > > I got to wondering for no particular reason which came first -- I had > always assumed cron, but ...? > > Anyone know? From lm at mcvoy.com Wed Dec 9 05:05:39 2020 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 8 Dec 2020 11:05:39 -0800 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: References: Message-ID: <20201208190539.GA3303@mcvoy.com> Doesn't it stand to reason that cron would come first, isn't at implemented with an entry in a crontab? On Tue, Dec 08, 2020 at 10:51:05AM -0800, Mary Ann Horton wrote: > My V6 manual has cron(VIII) - documentation of /usr/lib/crontab - but no > mention of at. > > This is consistent with my recollection - I first saw at in V7. > > ?????? Mary Ann > > On 12/8/20 10:11 AM, ron minnich wrote: > >When I got into Unix in 1976 cron and at were both there. > > > >I got to wondering for no particular reason which came first -- I had > >always assumed cron, but ...? > > > >Anyone know? -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From michael at kjorling.se Wed Dec 9 05:20:54 2020 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Tue, 8 Dec 2020 19:20:54 +0000 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: <20201208190539.GA3303@mcvoy.com> References: <20201208190539.GA3303@mcvoy.com> Message-ID: On 8 Dec 2020 11:05 -0800, from lm at mcvoy.com (Larry McVoy): > Doesn't it stand to reason that cron would come first, isn't at implemented > with an entry in a crontab? I don't know if it is implemented that way, but if you have cron, then I suspect you could implement some form of at with even a pretty simple shell script that runs once a minute (via cron) to parse a set of files to see what should be run now as opposed to later. If you have at but not cron, then implementing the other doesn't seem quite as straightforward. It would certainly still be possible, but it would definitely give rise to the question of "wouldn't it be real nice if I could set this task up to run on a recurring basis?" followed by "wouldn't it make more sense for the run-stuff-at-some-time task to run from the recurring-execution tool, than the other way around?". Certainly the step from cron to at seems fairly obvious; not all tasks that are to be executed at some point in time lend themselves well to a recurring nature. Sometimes you really want to do something just once, just not right now. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From clemc at ccc.com Wed Dec 9 05:39:58 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 8 Dec 2020 14:39:58 -0500 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: References: Message-ID: Correct. at was a v7-ism. Trying to put a nicer face on the idea - that is to say, I looked at the "at" command as a user-mode (command) front-end to cron so you didn't have to edit the crontab yourself. The later had been around as a system support idea, since at least 6th edition - maybe 5th. On Tue, Dec 8, 2020 at 1:51 PM Mary Ann Horton wrote: > My V6 manual has cron(VIII) - documentation of /usr/lib/crontab - but no > mention of at. > > This is consistent with my recollection - I first saw at in V7. > > Mary Ann > > On 12/8/20 10:11 AM, ron minnich wrote: > > When I got into Unix in 1976 cron and at were both there. > > > > I got to wondering for no particular reason which came first -- I had > > always assumed cron, but ...? > > > > Anyone know? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Dec 9 12:00:53 2020 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 9 Dec 2020 13:00:53 +1100 (EST) Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: References: <20201208190539.GA3303@mcvoy.com> Message-ID: On Tue, 8 Dec 2020, Michael Kjörling wrote: > If you have at but not cron, then implementing the other doesn't seem > quite as straightforward. It would certainly still be possible, but it > would definitely give rise to the question of "wouldn't it be real nice > if I could set this task up to run on a recurring basis?" followed by > "wouldn't it make more sense for the run-stuff-at-some-time task to run > from the recurring-execution tool, than the other way around?". I've never seen a *nix (since the 70s) that didn't have CRON (in one form or another)... And on my FreeBSD system, "atrun" is called every 5 minutes, so /etc/crontab will need to be edited for finer granularity. -- Dave From m.douglas.mcilroy at dartmouth.edu Wed Dec 9 14:35:24 2020 From: m.douglas.mcilroy at dartmouth.edu (M Douglas McIlroy) Date: Tue, 8 Dec 2020 23:35:24 -0500 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? Message-ID: 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 From clemc at ccc.com Thu Dec 10 01:40:19 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 9 Dec 2020 10:40:19 -0500 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: References: Message-ID: Amen Doug. On Tue, Dec 8, 2020 at 11:36 PM M Douglas McIlroy < m.douglas.mcilroy at dartmouth.edu> wrote: > 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". > But I offer a suggestion that another dimension that should be forgotten in time scale and the economics within. When things evolve they do so on different clocks that are not necessarily linear. *i.e. *what was 'better' (winning) today, but might not be considered so tomorrow, however could yet prove otherwise sometime later. I use programming languages as a great example... There was a huge C vs Pascal debate, that C 'won' - but I've always said the rise of C++ came from the Pascal folks that could say "C didn't win." From the ashes of C++ we have Java, Go, and Rust. My point is that "intelligent design" doesn't necessarily guarantee goodness or for that matter,complete logical thinking. My own take on this is what I call "Cole's Law" *Simple economics always beats sophisticated architecture.* What you call *organic evolution* is what I think of what makes the *best economic sense* for the user and that is a function of the time scale and available resources at the time of creation/deployment. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikke.karlsson at gmail.com Thu Dec 10 01:46:55 2020 From: nikke.karlsson at gmail.com (Niklas Karlsson) Date: Wed, 9 Dec 2020 16:46:55 +0100 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: References: Message-ID: Den ons 9 dec. 2020 kl 16:42 skrev Clem Cole : > > My point is that "intelligent design" doesn't necessarily guarantee > goodness or for that matter,complete logical thinking. > > My own take on this is what I call "Cole's Law" *Simple economics > always beats sophisticated architecture.* > What you call *organic evolution* is what I think of what makes the *best > economic sense* for the user and that is a function of the time scale and > available resources at the time of creation/deployment. > Makes sense. Just consider Multics, or IBM's "Future System". "Intelligent design" often becomes overambitious and elephantine. That's not to say you don't want to put thought into your designs, but such overambitious plans are a definite pitfall. Niklas -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Thu Dec 10 02:01:02 2020 From: bakul at iitbombay.org (Bakul Shah) Date: Wed, 9 Dec 2020 08:01:02 -0800 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: References: Message-ID: <88E7F8CE-DC08-44AB-BF12-EFD4C5958950@iitbombay.org> please don’t blame c++ on pascal folks. stroustrup had nothing to do with pascal. > On Dec 9, 2020, at 7:41 AM, Clem Cole wrote: > >  > Amen Doug. > >> On Tue, Dec 8, 2020 at 11:36 PM M Douglas McIlroy wrote: >> 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". > But I offer a suggestion that another dimension that should be forgotten in time scale and the economics within. > > When things evolve they do so on different clocks that are not necessarily linear. i.e. what was 'better' (winning) today, but might not be considered so tomorrow, however could yet prove otherwise sometime later. I use programming languages as a great example... There was a huge C vs Pascal debate, that C 'won' - but I've always said the rise of C++ came from the Pascal folks that could say "C didn't win." From the ashes of C++ we have Java, Go, and Rust. > > My point is that "intelligent design" doesn't necessarily guarantee goodness or for that matter,complete logical thinking. > > My own take on this is what I call "Cole's Law" Simple economics always beats sophisticated architecture. > What you call organic evolution is what I think of what makes the best economic sense for the user and that is a function of the time scale and available resources at the time of creation/deployment. > > Clem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Dec 10 02:11:25 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 9 Dec 2020 11:11:25 -0500 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: <88E7F8CE-DC08-44AB-BF12-EFD4C5958950@iitbombay.org> References: <88E7F8CE-DC08-44AB-BF12-EFD4C5958950@iitbombay.org> Message-ID: Ah .. but all the Pascal folks got on the C++ bandwagon when it was clear C had won. Frankly, the death of C++ IMO was all the crap added too it, but we have moved in COFF territory and off of Unix and Unix philosophy I think. On Wed, Dec 9, 2020 at 11:01 AM Bakul Shah wrote: > please don’t blame c++ on pascal folks. stroustrup had nothing to do with > pascal. > > On Dec 9, 2020, at 7:41 AM, Clem Cole wrote: > >  > Amen Doug. > > On Tue, Dec 8, 2020 at 11:36 PM M Douglas McIlroy < > m.douglas.mcilroy at dartmouth.edu> wrote: > >> 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". >> > But I offer a suggestion that another dimension that should be forgotten > in time scale and the economics within. > > When things evolve they do so on different clocks that are not > necessarily linear. *i.e. *what was 'better' (winning) today, but might > not be considered so tomorrow, however could yet prove otherwise sometime > later. I use programming languages as a great example... There was a > huge C vs Pascal debate, that C 'won' - but I've always said the rise of > C++ came from the Pascal folks that could say "C didn't win." From the > ashes of C++ we have Java, Go, and Rust. > > My point is that "intelligent design" doesn't necessarily guarantee > goodness or for that matter,complete logical thinking. > > My own take on this is what I call "Cole's Law" *Simple economics > always beats sophisticated architecture.* > What you call *organic evolution* is what I think of what makes the *best > economic sense* for the user and that is a function of the time scale and > available resources at the time of creation/deployment. > > Clem > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfoust at threedee.com Thu Dec 10 02:04:12 2020 From: jfoust at threedee.com (John Foust) Date: Wed, 09 Dec 2020 10:04:12 -0600 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: References: Message-ID: <20201209162822.7A20E944D6@minnie.tuhs.org> At 09:40 AM 12/9/2020, Clem Cole wrote: >My own take on this is what I call "Cole's Law"Â Â Simple economics always beats sophisticated architecture. I thought that was finely sliced cabbage with a tart salad dressing. - John From imp at bsdimp.com Thu Dec 10 02:40:00 2020 From: imp at bsdimp.com (Warner Losh) Date: Wed, 9 Dec 2020 09:40:00 -0700 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: References: Message-ID: On Wed, Dec 9, 2020 at 8:41 AM Clem Cole wrote: > Amen Doug. > > On Tue, Dec 8, 2020 at 11:36 PM M Douglas McIlroy < > m.douglas.mcilroy at dartmouth.edu> wrote: > >> 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". >> > But I offer a suggestion that another dimension that should be forgotten > in time scale and the economics within. > > When things evolve they do so on different clocks that are not > necessarily linear. *i.e. *what was 'better' (winning) today, but might > not be considered so tomorrow, however could yet prove otherwise sometime > later. I use programming languages as a great example... There was a > huge C vs Pascal debate, that C 'won' - but I've always said the rise of > C++ came from the Pascal folks that could say "C didn't win." From the > ashes of C++ we have Java, Go, and Rust. > > My point is that "intelligent design" doesn't necessarily guarantee > goodness or for that matter,complete logical thinking. > > My own take on this is what I call "Cole's Law" *Simple economics > always beats sophisticated architecture.* > What you call *organic evolution* is what I think of what makes the *best > economic sense* for the user and that is a function of the time scale and > available resources at the time of creation/deployment. > I agree, but I thought Cole's Law was thinly sliced cabbage. Warner > > Clem > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Thu Dec 10 02:53:55 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Wed, 09 Dec 2020 08:53:55 -0800 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: References: Message-ID: <202012091653.0B9Grteq1091160@darkstar.fourwinds.com> Warner Losh writes: > > I agree, but I thought Cole's Law was thinly sliced cabbage. > > Warner No, it's a song by Zero. From tytso at mit.edu Thu Dec 10 02:58:54 2020 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Wed, 9 Dec 2020 11:58:54 -0500 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: References: Message-ID: <20201209165854.GK52960@mit.edu> On Wed, Dec 09, 2020 at 10:40:19AM -0500, Clem Cole wrote: > My point is that "intelligent design" doesn't necessarily guarantee > goodness or for that matter,complete logical thinking. There are some really great quotes, mostly from Linus, but I saw at least one from Larry McVoy, here, on the subject of "Linux is all about evolution, not intelligent design" here: https://ipfs.io/ipfs/QmdA5WkDNALetBn4iFeSepHjdLGJdxPBwZyY47ir1bZGAK/comp/evolution.html One of the quotes from Linus that is most pertinent for TUHS from the above: > There was a overall architecture, from Dennis and Ken. Ask them. I'll bet you five bucks they'll agree with me, not with you. I've talked to both, but not really about this particular issue, so I might lose, but I think I've got the much better odds. If you want to see a system that was more thoroughly _designed_, you should probably point not to Dennis and Ken, but to systems like L4 and Plan-9, and people like Jochen Liedtk and Rob Pike. And notice how they aren't all that popular or well known? "Design" is like a religion - too much of it makes you inflexibly and unpopular. The very architecture of UNIX has very much been an evolution. Sure, there are some basic ideas, but basic ideas do not make a system. - Ted From bakul at iitbombay.org Thu Dec 10 03:05:43 2020 From: bakul at iitbombay.org (Bakul Shah) Date: Wed, 9 Dec 2020 09:05:43 -0800 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: References: Message-ID: Ah .. but I don’t know if they did! The implication that Pascal folks like complexity seems strange as Pascal is far simpler than C++ (not much larger than C) and C++ is no more type safe than C (both are less type safe than Pascal). Anyway I will stop now! > On Dec 9, 2020, at 8:11 AM, Clem Cole wrote: > >  > Ah .. but all the Pascal folks got on the C++ bandwagon when it was clear C had won. Frankly, the death of C++ IMO was all the crap added too it, but we have moved in COFF territory and off of Unix and Unix philosophy I think. > >> On Wed, Dec 9, 2020 at 11:01 AM Bakul Shah wrote: >> please don’t blame c++ on pascal folks. stroustrup had nothing to do with pascal. >> >>>> On Dec 9, 2020, at 7:41 AM, Clem Cole wrote: >>>> >>>  >>> Amen Doug. >>> >>>> On Tue, Dec 8, 2020 at 11:36 PM M Douglas McIlroy wrote: >>>> 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". >>> But I offer a suggestion that another dimension that should be forgotten in time scale and the economics within. >>> >>> When things evolve they do so on different clocks that are not necessarily linear. i.e. what was 'better' (winning) today, but might not be considered so tomorrow, however could yet prove otherwise sometime later. I use programming languages as a great example... There was a huge C vs Pascal debate, that C 'won' - but I've always said the rise of C++ came from the Pascal folks that could say "C didn't win." From the ashes of C++ we have Java, Go, and Rust. >>> >>> My point is that "intelligent design" doesn't necessarily guarantee goodness or for that matter,complete logical thinking. >>> >>> My own take on this is what I call "Cole's Law" Simple economics always beats sophisticated architecture. >>> What you call organic evolution is what I think of what makes the best economic sense for the user and that is a function of the time scale and available resources at the time of creation/deployment. >>> >>> Clem >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From drsalists at gmail.com Thu Dec 10 03:42:39 2020 From: drsalists at gmail.com (Dan Stromberg) Date: Wed, 9 Dec 2020 09:42:39 -0800 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: References: Message-ID: On Wed, Dec 9, 2020 at 9:08 AM Bakul Shah wrote: > Ah .. but I don’t know if they did! The implication that Pascal folks like > complexity seems strange as Pascal is far simpler than C++ (not much larger > than C) and C++ is no more type safe than C (both are less type safe than > Pascal). Anyway I will stop now! > I was one of the people who happily left Pascal behind to move to C. But in retrospect, I think the computing world would've been better off with Pascal, modified slightly to allow passing variable-length arrays (like TurboPascal). I never did make the move to C++ - I've written only a little code in it. Instead, when a lot of people were moving from C to C++ or Perl, I fished around and hit upon a little-known language called Python (OCaml was runner up). My management was practically nonexistent back then, so no one told me "No, use what everyone else is using!" -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Thu Dec 10 05:25:36 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 9 Dec 2020 14:25:36 -0500 (EST) Subject: [TUHS] Were cron and at done at the same time? Or one before the other? Message-ID: <20201209192536.9A55018C088@mercury.lcs.mit.edu> > From: Niklas Karlsson > Just consider Multics, or IBM's "Future System". Here's a nice irony for you: one of the key people in killing off FS was reported to me (by someone who should have known) to be Jerry Saltzer (of Multics fame). That wasn't the only time he did something like thst, either; when MIT leaned on him to take over Athena, the first thing he did was to take a lot of their ambitious system plans, and ditch them; they fell back to mostly 'off the shelf' stuff: pretty much vanilla 4.2, etc. Multics itself has an interesting story, quite different from the popular image among those who know little (or nothing) of it. The system, as it was when Honeywell pulled the plug on further generations of new hardware (in the mid-80's) was very different from the system as originally envisaged by MIT (in the mid-60's); it had undergone a massive amount 'experience-based evolution' during those 20 years. For instance, the original concept was to have a process per command (like Unix), but that was dropped early on (because Multics processes were too 'expensive'); they wound up going with doing commands with inter-segment procedure calls. (Which has the nice benefit that when a command faults, you can get dropped right into the debugger, with the failed instance there to look at.) If you read the Organick book on Multics, it describes a much different system: e.g. in Organick there's a 'linkage segment' (used for inter-segment pointers, in pure-code segments) per code segment, but in reality Multics, as distributed, used a single 'combined linkage segment' (which also contained the stack, also unlike the original design, where the stack was a separate segment). There were also numerous places where major sub-systems were re-implemeneted from scratch, with major changes (often great simplifications): one major re-do was the New Storage System, but that one had major new features (based on operationally-shown needs, like the 4.1/.2 Fast File System), so it's not a 'simplification' case. There's one I read about which was much simpler the second time it was implemented, I think it was IPC? Noel From crossd at gmail.com Thu Dec 10 05:58:27 2020 From: crossd at gmail.com (Dan Cross) Date: Wed, 9 Dec 2020 14:58:27 -0500 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: <20201209165854.GK52960@mit.edu> References: <20201209165854.GK52960@mit.edu> Message-ID: On Wed, Dec 9, 2020 at 12:07 PM Theodore Y. Ts'o wrote: > On Wed, Dec 09, 2020 at 10:40:19AM -0500, Clem Cole wrote: > > My point is that "intelligent design" doesn't necessarily guarantee > > goodness or for that matter,complete logical thinking. > > There are some really great quotes, mostly from Linus, but I saw at > least one from Larry McVoy, here, on the subject of "Linux is all > about evolution, not intelligent design" here: > > > https://ipfs.io/ipfs/QmdA5WkDNALetBn4iFeSepHjdLGJdxPBwZyY47ir1bZGAK/comp/evolution.html > > One of the quotes from Linus that is most pertinent for TUHS from the > above: > > > There was a overall architecture, from Dennis and Ken. > > Ask them. I'll bet you five bucks they'll agree with me, not with you. > Oh golly. Linus sure does have a special way of communicating. I've talked to both, but not really about this particular issue, so I > might lose, but I think I've got the much better odds. > If I understand the context here, it's that Linus is arguing against the sort of large-scale architectural "design" that plagues software projects that employ, say, the waterfall method, arguing in favor of organic evolution for Linux development. I guess that's fine, but evolution almost always favors a local maxima, and I don't think that's optimal in an absolute sense. But I also don't know another way to do it that doesn't get bogged down in the pursuit of perfection; it may be a necessary survival trait. I think that's a slightly disingenuous reading of what he's replying to, though; by the time Linus started working on Linux, there was a pretty well-defined Unix architecture in place that he was able to copy, very successfully. Sure, the details are up to the implementer, but to suggest that there wasn't a framework for his thinking about what Linux would look like just isn't true. > If you want to see a system that was more thoroughly _designed_, you > should probably point not to Dennis and Ken, but to systems like L4 and > Plan-9, and people like Jochen Liedtk and Rob Pike. > I'm not sure I would agree with this assessment about either L4 or Plan 9. Both evolved greatly over their lives, and both continue to evolve (though plan9's evolution is greatly diminished). And notice how they aren't all that popular or well known? "Design" is > like a religion - too much of it makes you inflexibly and unpopular. > That's a terrible metric. I submit that neither of those systems were created with the explicit goal to become "popular", and the claim of inflexibility is unwarranted. Within their domain, that is as research systems, both are quite well known and remain highly influential. This is a common but annoying line of thought in the computer world: because something is useful and popular, it is good. My first car was a 1985 AMC Eagle; it was undeniably useful. It may have even been moderately popular at one point. But damn it was an awful car. Linux is undeniably useful and it's arguably the most popular operating system in the world. And parts of it are really, really good. But simply put, that doesn't mean that its evolutionary path has landed in an inherently good place. To circle back to plan 9 for a moment, this was something that the open source folks who found their way to 9fans just couldn't grok. The answer to the question, "why don't you do all this work to support (emacs|a web browser|a C++ compiler|whatever du jour)?" was, "because there's little inherent research value in doing that, and this is a research system." That it was also a workaday system for a handful of folks was incidental; the goal wasn't world domination, it was advancing research and providing a comfortable environment for that work. Linus's response exemplifies this lack of understanding. (Disclaimer: I was very much an outsider looking in there, but it seems clear enough in retrospect.) The very architecture of UNIX has very much been an evolution. Sure, there are some basic ideas, but basic ideas do not make a system. > And yet, by the time that Linus started work on Linux, Unix already was a system and had been for 20 years. At the Unix 50th event at the LCM+L, Mary Ann and I spent a little time playing around with the original 7th Edition on a simulator, trying to write simple programs in B. There was certainly familiarity there, but it was simultaneously very foreign; the system was recognizable as an ancestor, but one very far back on the evolutionary timeline. If anything, changes due to Linux's evolution from its early days are far less pronounced, or perhaps I should say has been much more internally focused (I recognize that the kernel sources are unrecognizable from what Linux was putting onto Finnish FTP sites in 1991...). - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Dec 10 06:13:11 2020 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 10 Dec 2020 07:13:11 +1100 (EST) Subject: [TUHS] Happy birthday, Ada Lovelace and JFO! Message-ID: Sorta relevant to both groups... Augusta Ada King-Noel, Countess of Lovelace (and daughter of Lord Byron), was born on this day in 1815; arguably the world's first computer programmer and a highly independent woman, she saw the potential in Charles Babbage's new-fangled invention. J.F.Ossanna was given unto us on this day in 1928; a prolific programmer, he not only had a hand in developing Unix but also gave us the ROFF series. Who'ld've thought that two computer greats would share the same birthday? -- Dave From will.senn at gmail.com Thu Dec 10 06:30:30 2020 From: will.senn at gmail.com (Will Senn) Date: Wed, 9 Dec 2020 14:30:30 -0600 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: References: <20201209165854.GK52960@mit.edu> Message-ID: On 12/9/20 1:58 PM, Dan Cross wrote: > On Wed, Dec 9, 2020 at 12:07 PM Theodore Y. Ts'o > wrote: > > On Wed, Dec 09, 2020 at 10:40:19AM -0500, Clem Cole wrote: > > My point is that "intelligent design" doesn't necessarily guarantee > > goodness or for that matter,complete logical thinking. > > There are some really great quotes, mostly from Linus, but I saw at > least one from Larry McVoy, here, on the subject of "Linux is all > about evolution, not intelligent design" here: > > https://ipfs.io/ipfs/QmdA5WkDNALetBn4iFeSepHjdLGJdxPBwZyY47ir1bZGAK/comp/evolution.html > > > One of the quotes from Linus that is most pertinent for TUHS from the > above: > >     > There was a overall architecture, from Dennis and Ken. > >     Ask them. I'll bet you five bucks they'll agree with me, not > with you. > > Ugh! Seriously, evolution vs design? Implying that software can result from stochastic processes (an oxymoron, if ever there was one), is unlikely. These are semantic gyrations. Unix, was designed... back of a napkin, maybe, but it didn't appear out of the primordial ooze. It came out of an ordered mind, was realized, was revised and revised again, but always guided by an ordered intellect. That said, the use of the word evolution to refer to the gradual change of something into something else over time (another semantic gyration) certainly applies and I might refer the casual reader to Ritchie's article of similar title, The Evolution of the UNIX Time-Sharing System, as a great example of this use. Other than this tenuous connection, I'd call this COFF material. Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Thu Dec 10 09:22:29 2020 From: bakul at iitbombay.org (Bakul Shah) Date: Wed, 9 Dec 2020 15:22:29 -0800 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: <20201209165854.GK52960@mit.edu> References: <20201209165854.GK52960@mit.edu> Message-ID: On Dec 9, 2020, at 9:06 AM, Theodore Y. Ts'o wrote: > > If you want to see a system that was more thoroughly _designed_, you > should probably point not to Dennis and Ken, but to systems like L4 and > Plan-9, and people like Jochen Liedtk and Rob Pike. > > And notice how they aren't all that popular or well known? "Design" is > like a religion - too much of it makes you inflexibly and unpopular. I recently read an article that says in biology the “neutral theory” (random chance has a profound effect on genetics and evolution) is much more accepted now than Darwin & Wallace’s “Principle of Natural Selection” (survival of the fittest). This seems to apply here as well. Seems popularity has more to do with being in the right place at the right time. Both Plan9 & L4 are certainly more flexible. IMHO the “religion” we are suffering from is "speed" or rather too much attention to premature optimization in the small. Each layer may be efficient but too many layers get used so at the system level things are much worse: slower and so complex that no one person understands the system. While h/w performance and capacity has increased by orders of magnitude, s/w has frittered away most of it. This religion (including use of unsafe languages like C) has been largely responsible for most of the vulnerabilities. We end up using containers and virtual machines (VMs) to try counter these vulnerabilities. VMs are a sledgehammer that wouldn’t be required for isolation if all the user s/w ran on a secure-by-design kernel (or hardware). Note that even the h/w features vulnerable to security attacks were put in to improve performance. From cym224 at gmail.com Thu Dec 10 09:46:13 2020 From: cym224 at gmail.com (Nemo Nusquam) Date: Wed, 9 Dec 2020 18:46:13 -0500 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: References: Message-ID: On 12/09/20 12:42, Dan Stromberg wrote: > On Wed, Dec 9, 2020 at 9:08 AM Bakul Shah > wrote: > > Ah .. but I don’t know if they did! The implication that Pascal > folks like complexity seems strange as Pascal is far simpler than > C++ (not much larger than C) and C++ is no more type safe than C > (both are less type safe than Pascal). Anyway I will stop now! > > > I was one of the people who happily left Pascal behind to move to C. > But in retrospect, I think the computing world would've been better > off with Pascal, modified slightly to allow passing variable-length > arrays (like TurboPascal). As Wirth wrote, in retrospect he should have called it Pascal-2, not Modula-2. [COFF, COFF] N. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Thu Dec 10 09:51:33 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 10 Dec 2020 00:51:33 +0100 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: <20201209234435.CmOyp%steffen@sdaoden.eu> References: <20201209165854.GK52960@mit.edu> <20201209234435.CmOyp%steffen@sdaoden.eu> Message-ID: <20201209235133.BnAit%steffen@sdaoden.eu> Steffen Nurpmeso wrote in <20201209234435.CmOyp%steffen at sdaoden.eu>: |Bakul Shah wrote in | : ||On Dec 9, 2020, at 9:06 AM, Theodore Y. Ts'o wrote: ||> ||> If you want to see a system that was more thoroughly _designed_, you ||> should probably point not to Dennis and Ken, but to systems like \ ||> L4 and ||> Plan-9, and people like Jochen Liedtk and Rob Pike. ||> ||> And notice how they aren't all that popular or well known? "Design" is ||> like a religion - too much of it makes you inflexibly and unpopular. || ||I recently read an article that says in biology the “neutral ||theory” (random chance has a profound effect on genetics and ||evolution) is much more accepted now than Darwin & Wallace’s | |Eh. What these guys want is to push through "green" genetics with |massive lobby work. Your head is a toilet and those masses of |lobbyists throw their diarrhoea on to you regardless. |"Indifference has won won won". Of course: i have no idea, please listen to the specialists who know. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From steffen at sdaoden.eu Thu Dec 10 09:44:35 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 10 Dec 2020 00:44:35 +0100 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: References: <20201209165854.GK52960@mit.edu> Message-ID: <20201209234435.CmOyp%steffen@sdaoden.eu> Bakul Shah wrote in : |On Dec 9, 2020, at 9:06 AM, Theodore Y. Ts'o wrote: |> |> If you want to see a system that was more thoroughly _designed_, you |> should probably point not to Dennis and Ken, but to systems like L4 and |> Plan-9, and people like Jochen Liedtk and Rob Pike. |> |> And notice how they aren't all that popular or well known? "Design" is |> like a religion - too much of it makes you inflexibly and unpopular. | |I recently read an article that says in biology the “neutral |theory” (random chance has a profound effect on genetics and |evolution) is much more accepted now than Darwin & Wallace’s Eh. What these guys want is to push through "green" genetics with massive lobby work. Your head is a toilet and those masses of lobbyists throw their diarrhoea on to you regardless. "Indifference has won won won". --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From gnu at toad.com Thu Dec 10 10:19:06 2020 From: gnu at toad.com (John Gilmore) Date: Wed, 09 Dec 2020 16:19:06 -0800 Subject: [TUHS] Cole's Slaw In-Reply-To: References: Message-ID: <1479.1607559546@hop.toad.com> Clem Cole wrote: > My own take on this is what I call "Cole's Law" Simple economics > always beats sophisticated architecture. I'm with you, Clem! That certainly worked for closing the Digital Divide. Some suggested allocating billions in tax dollars to subsidize the un-networked in the 1990s and 2000's. Instead we mostly just waited a few years. Semiconductor economics plus consumer behavior (demand rises very quickly as prices drop, which provides economies of scale) solve most of the problem for you. (And in the 2020s Elon Musk and others have likely accumulated enough capital and tech to solve the Last 500 Mile problem -- aiming the dish straight up and to the horizons -- for rural and maritime digital divide issues.) Cole's Law has worked similarly for farm efficiency. Farms in 2020 are many times as efficient, on average, as they were 40 years ago, counting all the inputs (water, energy, land, human time, fertilizer, etc) and the outputs (food and waste products). That's why you can get whole cooked chickens for $8 at your local grocery, as just one example. That was not driven by detailed and complicated environmental regulations, or farm subsidies, but by straightforward economics. The more efficient producers drove out, or bought up, or trained, the inefficient ones. Information flowed from high efficiency farms to low efficiency ones, resources flowed the other way. Going back 140 years, it used to take 50% of the population to grow the food for 100% of us; now it takes less than 2% of the population. The US now has net farmland going back to wilderness every year, because we feed ourselves and the world with less land than it took last year. It also worked for scaling up the Internet. Not just from a few federally supported fat slow regionals and one skinny backbone, to thousands of ISP's (each of whom was self-supporting from customers, so their income would scale with the demand). Also worked for scaling to higher and higher bandwidths, riding both the Moore's Law economics of computation, and also the fiber optic economics of materials science and semiconductor laser/receiver evolution. Rather than complex systemantics around limiting, capping, scheduling, reserving, or otherwise restricting offered traffic, just cheaply make more headroom. Move everything to higher frequencies (including infrared light in fibers, and GHz in radio). Oops, a pandemic that scales up your traffic by 50% in a month and needs realtime latency for most of it? No problem, the economics caused us to build networks that handled that. (BTW, why is your home network still using 1-gigabit Ethernet, when 10-gig Ethernet cards are $100, cat6 or 6a cables cost almost the same as cat5, and 10GBASE-T switches are a few hundred dollars?) Humans tend to make poor decisions about exponential functions that go on for decades, because in evolution we so seldom saw that happen. But we're in the middle of one now, and it as much an exponential function in *economics* as it is in *technology*. John From lm at mcvoy.com Thu Dec 10 10:29:16 2020 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 9 Dec 2020 16:29:16 -0800 Subject: [TUHS] Cole's Slaw In-Reply-To: <1479.1607559546@hop.toad.com> References: <1479.1607559546@hop.toad.com> Message-ID: <20201210002916.GH3303@mcvoy.com> On Wed, Dec 09, 2020 at 04:19:06PM -0800, John Gilmore wrote: > (BTW, why is your home network still using 1-gigabit Ethernet, when > 10-gig Ethernet cards are $100, cat6 or 6a cables cost almost the same > as cat5, and 10GBASE-T switches are a few hundred dollars?) Because my ISP is below 100Mbit. And gigabit is fast enough for doing backups, which is the only time I care about performance. From fair-tuhs at netbsd.org Thu Dec 10 10:53:16 2020 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Wed, 09 Dec 2020 16:53:16 -0800 Subject: [TUHS] Cole's Slaw In-Reply-To: <20201210002916.GH3303@mcvoy.com> References: <1479.1607559546@hop.toad.com> Message-ID: <28537.1607561596@cesium.clock.org> I bet your backups across the gigabit switch to your NAS are (small) incrementals. You'll care about having 10gigE when you try a restore from backup. We have a very persistent problem with storage capacity versus I/O bandwidth, which I metaphor as "swimming pools of data, which we fill & drain with garden hoses." How many terabytes of stable storage do you have at home? Further, LANs have always lagged local I/O bandwidth (across PCI, PCIe, etc), independent of the nastiness introduced by latency and less-than-ideal data transfer protocols. Unix "diskless" workstations were only tolerable because the disks were still expensive and there were good reasons to share. Erik From cowan at ccil.org Thu Dec 10 11:49:43 2020 From: cowan at ccil.org (John Cowan) Date: Wed, 9 Dec 2020 20:49:43 -0500 Subject: [TUHS] Cole's Slaw In-Reply-To: <1479.1607559546@hop.toad.com> References: <1479.1607559546@hop.toad.com> Message-ID: On Wed, Dec 9, 2020 at 7:19 PM John Gilmore wrote: That certainly worked for closing the Digital Divide. Some suggested > allocating billions in tax dollars to subsidize the un-networked in the > 1990s and 2000's. Instead we mostly just waited a few years. > Semiconductor economics plus consumer behavior (demand rises very > quickly as prices drop, which provides economies of scale) solve most of > the problem for you. > Not quite yet. As of 2018, which is the latest data I can find, only 73% of U.S. households have 10 Mbps download speed or better, and only 46% have 100 Mbps service or better. If you look at the lowest quartile of household incomes, the figures are 33% and 18% respectively. (You want adoption figures, not deployment figures.) Wiring up the whole country is fine, but if people won't or can't use it, it does little good. On Wed, Dec 9, 2020 at 7:53 PM Erik E. Fair wrote: How many terabytes of stable storage do you have at home? > None at all, unless you count physical books. I don't bother with home backups because they don't provide disaster recovery: I'm not going to be thinking about grabbing a hard disk on my way out the door if there's a fire or flood. Instead, I keep about 186 GB in an S3 bucket (a fair amount of that is redundant, but it doesn't make sense for me to spend time deduplicating files). I also have about 4 GB in two Google accounts. Essentially all of that is text/plain, text/html, or application/pdf. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org Monday we watch-a Firefly's house, but he no come out. He wasn't home. Tuesday we go to the ball game, but he fool us. He no show up. Wednesday he go to the ball game, and we fool him. We no show up. Thursday was a double-header. Nobody show up. Friday it rained all day. There was no ball game, so we stayed home and we listened to it on-a the radio. --Chicolini -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Thu Dec 10 12:12:16 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Wed, 09 Dec 2020 18:12:16 -0800 Subject: [TUHS] Cole's Slaw In-Reply-To: References: <1479.1607559546@hop.toad.com> Message-ID: <202012100212.0BA2CGEd029177@darkstar.fourwinds.com> John Cowan writes: > > That certainly worked for closing the Digital Divide. Some suggested > > allocating billions in tax dollars to subsidize the un-networked in the > > 1990s and 2000's. Instead we mostly just waited a few years. > > Semiconductor economics plus consumer behavior (demand rises very > > quickly as prices drop, which provides economies of scale) solve most of > > the problem for you. > > > > Not quite yet. As of 2018, which is the latest data I can find, only 73% > of U.S. households have 10 Mbps download speed or better, and only 46% have > 100 Mbps service or better. If you look at the lowest quartile of > household incomes, the figures are 33% and 18% respectively. (You want > adoption figures, not deployment figures.) Wiring up the whole country is > fine, but if people won't or can't use it, it does little good. This is not a really TUHS topic. As one of those people who does not have decent internet service and am still waiting I'd be happy to see some money spent to broaden availability. This is not being a matter of waiting years, it's a matter of waiting decades so far. Access is an equity issue as it's essential for everything from participating in government, schooling, and almost every other aspect of life today. Maybe people with good service are willing to have everyone else wait but IMHO society isn't well served that way. Jon From ggm at algebras.org Thu Dec 10 13:10:18 2020 From: ggm at algebras.org (George Michaelson) Date: Thu, 10 Dec 2020 13:10:18 +1000 Subject: [TUHS] Cole's Slaw In-Reply-To: <28537.1607561596@cesium.clock.org> References: <1479.1607559546@hop.toad.com> <20201210002916.GH3303@mcvoy.com> <28537.1607561596@cesium.clock.org> Message-ID: I deployed cheap switches, to try and reduce contention on the WiFi segment in a 3bed flat. I suspect, switching is *slower* than good quality 4/5G. I deployed cheap unmanaged switches. I think I may need to re-consider. (it may be slower than good quality 5gz WIFi but I felt not, lots of concrete, so I went cables in walls. Professionally installed cables too) old cheap switches have high port speed, but low cross-backplane bandwidth. They basically don't do what they say on the label although I have no proof, my observation is that 100mbit is rarely achieved on a cheap switching backplane. I think most people won't notice. If you need to do the full-disk restore, or stream 4K at the same time as play some call-of-duty *and* do a full-disk streaming restore, I think you can destroy your cheap home switch quickly. I have been prepping a ZFS filestore and I calculate I'm getting 30mbit-sec end-to-end from 300mbit capable backplane hosts. The port speeds are gig. The actual capability once you get over the Raspberry Pi USB3 is a LOT less. (the receiver is a Pi4 with 8GB of memory, it should *not* be disk I/O bound) my various OSX Macs can do roaring speeds if you back-to-back connect them. Put them into the switching stuff, it drops off really quickly to boringly slow speeds. If you go out the fibre router to the public network, I think their contention model remains interesting: Stuff is being done in layer 2 to manage your bandwidth and the fibre which is capable of gig, is probably doing bizarre things to pretend to be slower. Forced bit-drop, random drop, long stalls. The framing at layer2 is really bizarre. they can do a LOT in layer 2, they don't talk about. we're all some kind of PPPo inside this, which feels pretty meh. Why did it have to be like this? Economies which (unlike Australia) don't do bandwidth limit for pricing disfunction, probably are saying :what do you mean: at this point. (The UK, you can get true gig to the home. Parts of the USA likewise. Lots of europe likewise. Here in Oz, although the bearer is capable, you can't afford the price they want to charge because they'd doing ROI sums to pay back $50b of spend, as quickly as possible) If your router is running the Broadcom chipset most of them are built around, Its switch is not really very big, in buffer space. My R7000 is a Broadcom BCM4709A0 and I don't think its doing very well. So, I'm dying inside because this is highly contestable FUD. If somebody with shares in the vendors chipset can tell me "you're just wrong' I'd believe them but my experience from the field is, white box domestic switches, and home routers, simply can't "do" full-bore gig on multiple paths across the switch at once. Ubiquity and other good vendors? Probably fine. Hell, for all I know, even Mikrotik might be ok, I've only ever had their toss-away freebies from conference Schwag and it was cool to have a box the size of a packet of cigarettes which run BGP, but they felt pretty slow (they even do portspan. amazing stuff) -G On Thu, Dec 10, 2020 at 10:53 AM Erik E. Fair wrote: > > I bet your backups across the gigabit switch to your NAS are (small) incrementals. > > You'll care about having 10gigE when you try a restore from backup. > > We have a very persistent problem with storage capacity versus I/O bandwidth, which I metaphor as "swimming pools of data, which we fill & drain with garden hoses." How many terabytes of stable storage do you have at home? > > Further, LANs have always lagged local I/O bandwidth (across PCI, PCIe, etc), independent of the nastiness introduced by latency and less-than-ideal data transfer protocols. Unix "diskless" workstations were only tolerable because the disks were still expensive and there were good reasons to share. > > Erik From dave at horsfall.org Sat Dec 12 12:56:42 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 12 Dec 2020 13:56:42 +1100 (EST) Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020, Clem Cole wrote: > My point is that   "intelligent design" doesn't necessarily guarantee > goodness or for that matter,complete logical thinking. Don't mention "intelligent design" in my hearing; it's just a fad term for creation theory... Look at Unix, for example :-) It didn't so much spring from the brow of Zeus i.e. Ken and Dennis, but has since evolved over decades (and it's still recognisable as Unix). -- Dave, using Unix since Edition 5 From scj at yaccman.com Sun Dec 13 05:10:16 2020 From: scj at yaccman.com (scj at yaccman.com) Date: Sat, 12 Dec 2020 11:10:16 -0800 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: References: Message-ID: <39d9058b9d69def8bfc1f58abaca928a@yaccman.com> As the inventor of "at", I can tell you that cron existed for quite some time, but was little used. An arcane set of manipulations was required to get things to run, and there was little demand. But there were a bunch of us all using the same PDP-11, and I wanted to add a job to run at 3AM that would be a bit of CPU hog. I struggled and finally got something to work. And thinking about it, I realized that what I really wanted to say was at 3am command-line I made a shell script that did the bare minimum and advertised it on motd. Within a day or two, Dennis grabbed it and made sure that the job would run in the proper directory with the correct permissions, and otherwise behave the way I wanted it to. As many of you know, the rule with Unix was "you can touch anything, but if you change it, you own it." This was a great way to turn arguments into progress. I think I "owned" at for at most two days. I had a similar experience with spell--I think my ownership of spell lasted about 2 weeks. In both cases, I was delighted to provide the "sperm of the idea" and let someone else carry and deliver the baby. --- On 2020-12-11 18:56, Dave Horsfall wrote: > On Wed, 9 Dec 2020, Clem Cole wrote: > >> My point is that   "intelligent design" doesn't necessarily guarantee >> goodness or for that matter,complete logical thinking. > > Don't mention "intelligent design" in my hearing; it's just a fad > term for creation theory... > > Look at Unix, for example :-) It didn't so much spring from the brow > of Zeus i.e. Ken and Dennis, but has since evolved over decades (and > it's still recognisable as Unix). > > -- Dave, using Unix since Edition 5 From scj at yaccman.com Sun Dec 13 05:50:50 2020 From: scj at yaccman.com (scj at yaccman.com) Date: Sat, 12 Dec 2020 11:50:50 -0800 Subject: [TUHS] The UNIX Command Language (1976) In-Reply-To: <202012011639.0B1GdjcD031722@freefriends.org> References: <15511090.6330.1606835354160.JavaMail.root@zimbraanteil> <202012011538.0B1FcLi5023858@freefriends.org> <202012011639.0B1GdjcD031722@freefriends.org> Message-ID: <5fde7febb4ac642817c1e612514ffd8d@yaccman.com> When I wrote yacc, my first thought was to use goto's when implementing the finite state machine that is the heart of the parser. That's how FSM's work! I got the code written, but the C compiler complained and wouldn't compile. It turned out that, while goto was implemented in C, you could only have 10 of them! So I had to use a switch statement. I also recently came upon one of my first C programs -- I wrote a "go fish" game for my son as a practice in using the language. Reading the code was most instructive: 1. I had used FOUR gotos! I can't remember the last time I wrote a goto... 2. The program had a bug -- char being used as an int. Gave an advantage to the player. 3. The game was surprisingly hard to beat. I had to add a "dumb me down" flag because my kids never won. I think the game was distributed in some of the early releases. At one point, at a conference, the speaker accused the game of cheating! The game was just very good at remembering that if the player had asked it for a 6, and then it drew a 6 later, it would ask the player for 6 again. On 2020-12-01 08:39, arnold at skeeve.com wrote: >> On Tue, Dec 1, 2020 at 8:39 AM wrote: >> > It was recognized that goto was not necessary if one had proper control >> > structures in a language (if/else, while), and that code with no (or >> > minimal) gotos was easier to read and understand. From dave at horsfall.org Sun Dec 13 07:11:37 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 13 Dec 2020 08:11:37 +1100 (EST) Subject: [TUHS] Cole's Slaw In-Reply-To: <20201210002916.GH3303@mcvoy.com> References: <1479.1607559546@hop.toad.com> <20201210002916.GH3303@mcvoy.com> Message-ID: On Wed, 9 Dec 2020, Larry McVoy wrote: > Because my ISP is below 100Mbit. And gigabit is fast enough for doing > backups, which is the only time I care about performance. Indeed. I don't do video streaming (I have something called "advert-free free to air television") but I do a lot of software updates, so I care more about download limits than speed. As a result, my current plan is unlimited download bytes, but my download speed is 50Mb/s; I can wait (my MacBook's updates happen overnight anyway)... My (wireless) LAN is around 250MB/sec; I don't care about speed so much as capacity. -- Dave From tytso at mit.edu Sun Dec 13 11:07:43 2020 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Sat, 12 Dec 2020 20:07:43 -0500 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: References: <20201209165854.GK52960@mit.edu> Message-ID: <20201213010743.GE575698@mit.edu> On Wed, Dec 09, 2020 at 02:58:27PM -0500, Dan Cross wrote: > To circle back to plan 9 for a moment, this was something that the open > source folks who found their way to 9fans just couldn't grok. The answer to > the question, "why don't you do all this work to support (emacs|a web > browser|a C++ compiler|whatever du jour)?" was, "because there's little > inherent research value in doing that, and this is a research system." That > it was also a workaday system for a handful of folks was incidental; the > goal wasn't world domination, it was advancing research and providing a > comfortable environment for that work. Linus's response exemplifies this > lack of understanding. (Disclaimer: I was very much an outsider looking in > there, but it seems clear enough in retrospect.) There was a similar dynamic with Minix, where Prof. Tanenbaum rejected contributions to Minix because Minix wa a teaching system, and he wanted to keep it simple. The contrast is that with Linux, that contributions are accepted from a large number of people, working at a large number of companies, that all have different goals, and the challenge of maintainers is to balance off the goals of many different contributors. Contributions don't get rejected just because "this is a {research,testing} OS". The goal is to make the open source project as generally useful as possible. > And notice how they aren't all that popular or well known? "Design" is > > like a religion - too much of it makes you inflexibly and unpopular. > > That's a terrible metric. > > I submit that neither of those systems were created with the explicit goal > to become "popular", and the claim of inflexibility is unwarranted. Within > their domain, that is as research systems, both are quite well known and > remain highly influential. >From the open source perspective, it's an extremely important metric, since if a system is generally useful, such that many different entities find the system to be useful, that means that the project will have more and more contributors. Yes, those contributors may have differing objectives, but this also gives you a larger development community to make the project more useful. The challenge is how to structure the project so that you can usefully use a larger and larger number of contributors, and how to mediate conflicts when objectives are in tension with each other. (For example, sometimes adding lots of fine-grained locking to improve CPU scalability often comes at the cost of trashing UP and small SMP performance.) However, it's surprising how often that with the right amount of encouragement, things like SMP vs UP performance is not an either/or, but a both/and. Granted, at the extremes, this isn't always going to be true. If you have to squeeze an OS into super-tiny micro-controller, or if you want to optimize scalability for a massiely large Sunfire E10k/E12k/E15k server, the only way to do this is with a huge number of fine-grained locks in Solaris. (And given the profit margins on million dollar E10k versus a cheap Ultrasparc 5 workstation, it's not surprising that Solaris would optimize performance for an E10k.) > This is a common but annoying line of thought in the computer world: > because something is useful and popular, it is good. My first car was a > 1985 AMC Eagle; it was undeniably useful. It may have even been moderately > popular at one point. But damn it was an awful car. > > Linux is undeniably useful and it's arguably the most popular operating > system in the world. And parts of it are really, really good. But simply > put, that doesn't mean that its evolutionary path has landed in an > inherently good place. The question is what your objective function such that you consider the endpoint evolutionary path is "a good place"? My pre-existing values are that a system is "good" if it can add value for many different applications. So I have a bit of an engineer's perspective of a system is good because it is useful --- and part of being useful is that it is secure, and reliable, and cost effective. Having a clean architecture is useful in so far as it makes reduces maintenance overhead and improves reliability. But forcing everything to use a file interface merely for aethestics' sake is not terribly important for _my_ objective function. And if popularity means that I can have engineers from Tencent, and Huawei, and IBM, and SuSE, and Oracle, and Google all helping me make a better file system for Linux, as opposed to having one company shoulder all of the development costs --- then heck yes, I'll take popularity any day. Cheers, - Ted From jon at fourwinds.com Sun Dec 13 11:56:41 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Sat, 12 Dec 2020 17:56:41 -0800 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: <20201213010743.GE575698@mit.edu> References: <20201209165854.GK52960@mit.edu> <20201213010743.GE575698@mit.edu> Message-ID: <202012130156.0BD1ufbY2698480@darkstar.fourwinds.com> Theodore Y. Ts'o writes: > > Linux is undeniably useful and it's arguably the most popular operating > > system in the world. And parts of it are really, really good. But simply > > put, that doesn't mean that its evolutionary path has landed in an > > inherently good place. > > The question is what your objective function such that you consider > the endpoint evolutionary path is "a good place"? My pre-existing > values are that a system is "good" if it can add value for many > different applications. > > So I have a bit of an engineer's perspective of a system is good > because it is useful --- and part of being useful is that it is > secure, and reliable, and cost effective. Having a clean architecture > is useful in so far as it makes reduces maintenance overhead and > improves reliability. But forcing everything to use a file interface > merely for aethestics' sake is not terribly important for _my_ > objective function. > > And if popularity means that I can have engineers from Tencent, and > Huawei, and IBM, and SuSE, and Oracle, and Google all helping me make > a better file system for Linux, as opposed to having one company > shoulder all of the development costs --- then heck yes, I'll take > popularity any day. My two cents here is that the problem with the evolution of linux is that many, many people are adding new stuff while the existing stuff is decaying. Sure, the kernel is pretty stable, but user land is a mess where one has a choice of many versions of everything, each of which is broken in a different way. My engineer's perspective is that the overcomplexity from lack of architecture is resulting in reliability and maintenance issues. And, if you can actually make a better file system, please go for it, you're a better person than me. I've looked that that code, and it's huge, has no clearly defined entry and exit points, and is undocumented. While I've been too busy to deal with stuff, I found some minor bugs and a possible big performance improvement just from trying to read the code. I don't think that "it mostly works most of the time" is a great metric. Jon From jnc at mercury.lcs.mit.edu Sun Dec 13 12:02:19 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 12 Dec 2020 21:02:19 -0500 (EST) Subject: [TUHS] Were cron and at done at the same time? Or one before the other? Message-ID: <20201213020219.85F3D18C0A6@mercury.lcs.mit.edu> > From: "Theodore Y. Ts'o" > Having a clean architecture is useful in so far as it makes reduces > maintenance overhead and improves reliability. I would put it differently, hence my aphorism that: "the sign of great architecture is not how well it does the things it was designed to do, but how well it does things you never imagined it would be used for". I suppose you could say that reducing maintenance and improving reliability are examples of the natural consequences of that, but to me those are limited special cases of the more general statement. My sense is that systems decline over time because of what I call 'system cancer': as they are modified to do more and more (new) things, the changes are not usually very cleanly integrated, and eventually one winds up with a big pile. (Examples of this abound; I'm sure we can all think of several.) Noel From clemc at ccc.com Sun Dec 13 12:08:45 2020 From: clemc at ccc.com (Clem Cole) Date: Sat, 12 Dec 2020 21:08:45 -0500 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: <20201213020219.85F3D18C0A6@mercury.lcs.mit.edu> References: <20201213020219.85F3D18C0A6@mercury.lcs.mit.edu> Message-ID: Amen On Sat, Dec 12, 2020 at 9:02 PM Noel Chiappa wrote: > > From: "Theodore Y. Ts'o" > > > Having a clean architecture is useful in so far as it makes reduces > > maintenance overhead and improves reliability. > > I would put it differently, hence my aphorism that: "the sign of great > architecture is not how well it does the things it was designed to do, but > how > well it does things you never imagined it would be used for". > > I suppose you could say that reducing maintenance and improving reliability > are examples of the natural consequences of that, but to me those are > limited > special cases of the more general statement. My sense is that systems > decline > over time because of what I call 'system cancer': as they are modified to > do > more and more (new) things, the changes are not usually very cleanly > integrated, and eventually one winds up with a big pile. (Examples of this > abound; I'm sure we can all think of several.) > > Noel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Sun Dec 13 12:58:31 2020 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Sat, 12 Dec 2020 21:58:31 -0500 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: <202012130156.0BD1ufbY2698480@darkstar.fourwinds.com> References: <20201209165854.GK52960@mit.edu> <20201213010743.GE575698@mit.edu> <202012130156.0BD1ufbY2698480@darkstar.fourwinds.com> Message-ID: <20201213025831.GF575698@mit.edu> On Sat, Dec 12, 2020 at 05:56:41PM -0800, Jon Steinhart wrote: > > My two cents here is that the problem with the evolution of linux is that > many, many people are adding new stuff while the existing stuff is decaying. > Sure, the kernel is pretty stable, but user land is a mess where one has a > choice of many versions of everything, each of which is broken in a different > way. My engineer's perspective is that the overcomplexity from lack of > architecture is resulting in reliability and maintenance issues. There are areas that are broken, but I suspect you're remember the past with rose colored classes. I remember plenty of bugs and short-comings in BSD and commercial Unix systems in the late 80's and early 90's. They tended to show up for people who used those systems in ways that were a bit off the beaten path compared to the more common cases; but isn't that always the case? > And, if you can actually make a better file system, please go for it, you're > a better person than me. I've looked that that code, and it's huge, has no > clearly defined entry and exit points, and is undocumented. While I've been > too busy to deal with stuff, I found some minor bugs and a possible big > performance improvement just from trying to read the code. Did you report those bugs and potential performance improements? Feedback is always gratefully accepted. As far as documentation is concerned, it's not perfect, but it's certainly not completely undocumented: https://www.kernel.org/doc/html/latest/filesystems/index.html https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html Again, I suspect that you're remember the past with rose-colored classes. BSD FFS's fsck (or for that matter, fsck's from any of the commercial Unix systems that I was able to see soures for) didn't have regression test suites. Ext2/3/4 was one of the first file system fsck's that I'm aware with that was created with a regression test suite from the very beginning. And all of the major file systems in Linux are developed using a very large library of functional and stress tests: https://thunk.org/gce-xfstests https://thunk.org/android-xfstests https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-xfstests.md Was there anything like this during the "good old days"? I sure don't remember anything like this when I started with BSD 4.3 back in the late 80's... - Ted From crossd at gmail.com Sun Dec 13 13:02:43 2020 From: crossd at gmail.com (Dan Cross) Date: Sat, 12 Dec 2020 22:02:43 -0500 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: <20201213010743.GE575698@mit.edu> References: <20201209165854.GK52960@mit.edu> <20201213010743.GE575698@mit.edu> Message-ID: On Sat, Dec 12, 2020 at 8:07 PM Theodore Y. Ts'o wrote: > On Wed, Dec 09, 2020 at 02:58:27PM -0500, Dan Cross wrote: > > To circle back to plan 9 for a moment, this was something that the open > > source folks who found their way to 9fans just couldn't grok. The answer > to > > the question, "why don't you do all this work to support (emacs|a web > > browser|a C++ compiler|whatever du jour)?" was, "because there's little > > inherent research value in doing that, and this is a research system." > That > > it was also a workaday system for a handful of folks was incidental; the > > goal wasn't world domination, it was advancing research and providing a > > comfortable environment for that work. Linus's response exemplifies this > > lack of understanding. (Disclaimer: I was very much an outsider looking > in > > there, but it seems clear enough in retrospect.) > > There was a similar dynamic with Minix, where Prof. Tanenbaum rejected > contributions to Minix because Minix wa a teaching system, and he > wanted to keep it simple. > Yes, but his aim there was pedagogy, not general use. In that I would argue that he was successful. The contrast is that with Linux, that contributions are accepted from > a large number of people, working at a large number of companies, that > all have different goals, and the challenge of maintainers is to > balance off the goals of many different contributors. Contributions > don't get rejected just because "this is a {research,testing} OS". > The goal is to make the open source project as generally useful as > possible. Sure, but that's Linux. Linux is not (Minix|Plan9|L4). QED, no? Judging (Minix|Plan9|L4) by the same metrics by which one judges Linux is not useful if those systems never aspired to those metrics. > And notice how they aren't all that popular or well known? "Design" is > > > like a religion - too much of it makes you inflexibly and > unpopular. > > > > That's a terrible metric. > > > > I submit that neither of those systems were created with the explicit > goal > > to become "popular", and the claim of inflexibility is unwarranted. > Within > > their domain, that is as research systems, both are quite well known and > > remain highly influential. > > From the open source perspective, it's an extremely important metric, > But the systems Linus mentioned weren't trying to be "successful" open source systems by that definition. That's the point: the central thesis here is that _that may be an important metric for Linux_, and by that metric, Linux is very successful. However Linus Torvalds is suggesting that other systems that explicitly didn't judge themselves along those metrics are _unsuccessful_ in an absolute sense because they didn't "succeed" by the metrics along which Linux succeeded. This is analogous to suggesting that Yo-Yo Ma isn't "successful" because he can't dunk a basketball like Michael Jordan, and consequently isn't as famous. I'm willing to bet that more people know Jordan's name than Ma's, and Ma himself would likely be among the first to admit he's not NBA material, but that doesn't mean he isn't wildly successful as a classically trained cellist. For that matter, Mick Jagger is probably better known than Yo-Yo Ma, but I don't think the latter ever aspired to be the frontman for the Rolling Stones, but I would never suggest that he isn't an accomplished musician as a result. Recall that the original context was a defense of Linux's purely organic evolution vs some notion of "design up front" that Linus suggests both L4 and Plan9 sprang from. Nevermind that that is almost certainly not true of either L4 or plan 9, but rather it's nonsensical to suggest that a more design-oriented focus was the reason they weren't as successful as Linux (as measured by popularity and deployment) as it completely ignores that neither L4 nor plan9 were trying to do what Linux did in the first place. since if a system is generally useful, such that many different > entities find the system to be useful, that means that the project > will have more and more contributors. Yes, those contributors may > have differing objectives, but this also gives you a larger > development community to make the project more useful. > At one time, MS-DOS was wildly successful. There was a ton of software written for it. That software was useful to a lot of people. But it would be hard to argue that DOS was "better" on some technical plane than Unix. I realize that some of this is moving the goalposts because no one defined what "good" means in context. My definition includes things like complexity, maintainability, and elegance. Some parts of Linux are nice here; some ... not so much. The challenge is how to structure the project so that you can usefully > use a larger and larger number of contributors, and how to mediate > conflicts when objectives are in tension with each other. (For > example, sometimes adding lots of fine-grained locking to improve CPU > scalability often comes at the cost of trashing UP and small SMP > performance.) > > However, it's surprising how often that with the right amount of > encouragement, things like SMP vs UP performance is not an either/or, > but a both/and. Granted, at the extremes, this isn't always going to > be true. If you have to squeeze an OS into super-tiny > micro-controller, or if you want to optimize scalability for a > massiely large Sunfire E10k/E12k/E15k server, the only way to do this > is with a huge number of fine-grained locks in Solaris. (And given > the profit margins on million dollar E10k versus a cheap Ultrasparc 5 > workstation, it's not surprising that Solaris would optimize > performance for an E10k.) > > > This is a common but annoying line of thought in the computer world: > > because something is useful and popular, it is good. My first car was a > > 1985 AMC Eagle; it was undeniably useful. It may have even been > moderately > > popular at one point. But damn it was an awful car. > > > > Linux is undeniably useful and it's arguably the most popular operating > > system in the world. And parts of it are really, really good. But simply > > put, that doesn't mean that its evolutionary path has landed in an > > inherently good place. > > The question is what your objective function such that you consider > the endpoint evolutionary path is "a good place"? Yes, I cheated here by not offering a definition. My pre-existing > values are that a system is "good" if it can add value for many > different applications. > Well, my AMC Eagle got me around town, I drove to Bell Labs and back (from central PA) in it when I was 16, and it had a hitch attachment that could haul a camper. The engine was awesome and so was the heater, but every time I drove over a speedbump a part fell off. If it was "good" by the metric of adding value for different applications, then a car that did the same things and where the rearview _didn't_ fall off every time I ran over a pothole would have been better. So I have a bit of an engineer's perspective of a system is good > because it is useful --- and part of being useful is that it is > secure, and reliable, and cost effective. Having a clean architecture > is useful in so far as it makes reduces maintenance overhead and > improves reliability. But forcing everything to use a file interface > merely for aethestics' sake is not terribly important for _my_ > objective function. > One might argue that that misses the point of the interface: using the file interface now allows pretty much all resources to be shared over the network transparently, for example. Was it a purely aesthetic decision, or was it a research angle that opened up new areas for exploration? Indeed, some of the ideas that fell out of that as a consequence of "forcing" everything to look like a file are now in Linux. Per-process namespaces and /proc are obvious examples. But taking it back to Linus's point...Whether one system uses that file interface and another does not is immaterial, and I don't know that anyone seriously argued that the popularity of the system wasn't predicated on that. What you're describing here is a consequence of Linux's popularity; Linux wasn't more popular than plan9 necessarily because it had mmap and sockets and TTYs, but rather because it cloned an existing design that was already very popular and packaged that up free of the legal and financial entanglements of Unix, and also because plan9 just _wasn't trying to be popular in the same way_. And if popularity means that I can have engineers from Tencent, and > Huawei, and IBM, and SuSE, and Oracle, and Google all helping me make > a better file system for Linux, as opposed to having one company > shoulder all of the development costs --- then heck yes, I'll take > popularity any day. > That's fair, but that wasn't the original context. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Sun Dec 13 13:07:15 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Sat, 12 Dec 2020 19:07:15 -0800 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: <20201213025831.GF575698@mit.edu> References: <20201209165854.GK52960@mit.edu> <20201213010743.GE575698@mit.edu> <202012130156.0BD1ufbY2698480@darkstar.fourwinds.com> <20201213025831.GF575698@mit.edu> Message-ID: <202012130307.0BD37F0U2780521@darkstar.fourwinds.com> Theodore Y. Ts'o writes: > > And, if you can actually make a better file system, please go for it, you're > > a better person than me. I've looked that that code, and it's huge, has no > > clearly defined entry and exit points, and is undocumented. While I've been > > too busy to deal with stuff, I found some minor bugs and a possible big > > performance improvement just from trying to read the code. > > Did you report those bugs and potential performance improements? > Feedback is always gratefully accepted. > > As far as documentation is concerned, it's not perfect, but it's > certainly not completely undocumented: > > https://www.kernel.org/doc/html/latest/filesystems/index.html > https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html > > Again, I suspect that you're remember the past with rose-colored > classes. BSD FFS's fsck (or for that matter, fsck's from any of the > commercial Unix systems that I was able to see soures for) didn't have > regression test suites. Ext2/3/4 was one of the first file system > fsck's that I'm aware with that was created with a regression test > suite from the very beginning. And all of the major file systems in > Linux are developed using a very large library of functional and > stress tests: No, not yet, because I haven't had the time to test. And sorry, I wasn't clear. I wasn't talking about the code for a particular filesystem, I was talking about the generic filesystem code. Jon From tytso at mit.edu Mon Dec 14 02:49:16 2020 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Sun, 13 Dec 2020 11:49:16 -0500 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: <202012130307.0BD37F0U2780521@darkstar.fourwinds.com> References: <20201209165854.GK52960@mit.edu> <20201213010743.GE575698@mit.edu> <202012130156.0BD1ufbY2698480@darkstar.fourwinds.com> <20201213025831.GF575698@mit.edu> <202012130307.0BD37F0U2780521@darkstar.fourwinds.com> Message-ID: <20201213164916.GG575698@mit.edu> On Sat, Dec 12, 2020 at 07:07:15PM -0800, Jon Steinhart wrote: > Theodore Y. Ts'o writes: > > > And, if you can actually make a better file system, please go for it, you're > > > a better person than me. I've looked that that code, and it's huge, has no > > > clearly defined entry and exit points, and is undocumented. While I've been > > > too busy to deal with stuff, I found some minor bugs and a possible big > > > performance improvement just from trying to read the code. > > > > Did you report those bugs and potential performance improements? > > Feedback is always gratefully accepted. > > > > As far as documentation is concerned, it's not perfect, but it's > > certainly not completely undocumented: > > > > https://www.kernel.org/doc/html/latest/filesystems/index.html > > ... > > And sorry, I wasn't clear. I wasn't talking about the code for a > particular filesystem, I was talking about the generic filesystem > code. It's certainly not perfect; if you'd like to suggest improvements, again, they would be gratefully accepted, the first link I sent you was documentation for the generic file system code, and while there is certainly more that I'd love to see documented (improvements and bug reports gratefully accepted), the entry points are certainly one of the things that is quite well defined: https://www.kernel.org/doc/html/latest/filesystems/vfs.html Cheers, - Ted From jon at fourwinds.com Mon Dec 14 05:06:06 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Sun, 13 Dec 2020 11:06:06 -0800 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? [ really linux and filesystems ] In-Reply-To: <20201213164916.GG575698@mit.edu> References: <20201209165854.GK52960@mit.edu> <20201213010743.GE575698@mit.edu> <202012130156.0BD1ufbY2698480@darkstar.fourwinds.com> <20201213025831.GF575698@mit.edu> <202012130307.0BD37F0U2780521@darkstar.fourwinds.com> <20201213164916.GG575698@mit.edu> Message-ID: <202012131906.0BDJ665f2998021@darkstar.fourwinds.com> Theodore Y. Ts'o writes: > On Sat, Dec 12, 2020 at 07:07:15PM -0800, Jon Steinhart wrote: > > Theodore Y. Ts'o writes: > > > > And, if you can actually make a better file system, please go for it, you're > > > > a better person than me. I've looked that that code, and it's huge, has no > > > > clearly defined entry and exit points, and is undocumented. While I've been > > > > too busy to deal with stuff, I found some minor bugs and a possible big > > > > performance improvement just from trying to read the code. > > > > > > Did you report those bugs and potential performance improements? > > > Feedback is always gratefully accepted. > > > > > > As far as documentation is concerned, it's not perfect, but it's > > > certainly not completely undocumented: > > > > > > https://www.kernel.org/doc/html/latest/filesystems/index.html > > > ... > > > > And sorry, I wasn't clear. I wasn't talking about the code for a > > particular filesystem, I was talking about the generic filesystem > > code. > > It's certainly not perfect; if you'd like to suggest improvements, > again, they would be gratefully accepted, the first link I sent you > was documentation for the generic file system code, and while there is > certainly more that I'd love to see documented (improvements and bug > reports gratefully accepted), the entry points are certainly one of > the things that is quite well defined: > > https://www.kernel.org/doc/html/latest/filesystems/vfs.html > > Cheers, > > - Ted This isn't really on-topic for TUHS so I'll give you a longer answer by private email. Yes, I agree that there is documentation for parts of the code, some of which even refers to the current version. Been through a good pile of it. Still no clue as to the entry points in namei.c. Jon From dave at horsfall.org Tue Dec 15 06:28:01 2020 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 15 Dec 2020 07:28:01 +1100 (EST) Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: <88E7F8CE-DC08-44AB-BF12-EFD4C5958950@iitbombay.org> References: <88E7F8CE-DC08-44AB-BF12-EFD4C5958950@iitbombay.org> Message-ID: On Wed, 9 Dec 2020, Bakul Shah wrote: > please don’t blame c++ on pascal folks. stroustrup had nothing to do > with pascal.   I certainly hope not; Pascal was meant to be a teaching language, not a production language. As for C++, well, what can I say? It should've been called C-- ... You wrote your algorithm in Pascal, debugged it, and then rewrote it in your favourite language (in my case, ALGOL-W). -- Dave From thomas.paulsen at firemail.de Tue Dec 15 08:23:12 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Mon, 14 Dec 2020 23:23:12 +0100 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: References: <88E7F8CE-DC08-44AB-BF12-EFD4C5958950@iitbombay.org> Message-ID: <1276c9ee5cf400a13183437846e628e8@firemail.de> for pascal Niklaus Emil Wirth is the key and not Ken&Dennis. --- Ursprüngliche Nachricht --- Von: Dave Horsfall Datum: 14.12.2020 21:28:01 An: The Eunuchs Hysterical Society Betreff: Re: [TUHS] Were cron and at done at the same time? Or one before the other? On Wed, 9 Dec 2020, Bakul Shah wrote: > please don’t blame c++ on pascal folks. stroustrup had nothing to do > with pascal.   I certainly hope not; Pascal was meant to be a teaching language, not a production language. As for C++, well, what can I say? It should've been called C-- ... You wrote your algorithm in Pascal, debugged it, and then rewrote it in your favourite language (in my case, ALGOL-W). -- Dave From andrew at humeweb.com Tue Dec 15 09:04:15 2020 From: andrew at humeweb.com (Andrew Hume) Date: Mon, 14 Dec 2020 15:04:15 -0800 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: <1276c9ee5cf400a13183437846e628e8@firemail.de> References: <88E7F8CE-DC08-44AB-BF12-EFD4C5958950@iitbombay.org> <1276c9ee5cf400a13183437846e628e8@firemail.de> Message-ID: i remember going to a wirth talk in sydney with john lions. the discussion of the day was john trying to persuade niklaus about the value of multiprogramming. “why would you want to do anything else while your computer was printing?” it was a long discussion. > On Dec 14, 2020, at 2:23 PM, Thomas Paulsen wrote: > > for pascal Niklaus Emil Wirth is the key and not Ken&Dennis. > From skogtun at gmail.com Tue Dec 15 09:59:54 2020 From: skogtun at gmail.com (Harald Arnesen) Date: Tue, 15 Dec 2020 00:59:54 +0100 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: References: <88E7F8CE-DC08-44AB-BF12-EFD4C5958950@iitbombay.org> Message-ID: <7e66e5eb-6cea-5403-a2cc-e8d93f038e66@gmail.com> Dave Horsfall [14.12.2020 21:28]: > You wrote your algorithm in Pascal, debugged it, and then rewrote it in > your favourite language (in my case, ALGOL-W). Now THATS's a sane language. I have never used it professionally (or much at all), but I can see it's what Algol-687 should have been. Even better than Simula, which I have used a bit in the past. -- Hilsen Harald From bakul at iitbombay.org Tue Dec 15 12:57:06 2020 From: bakul at iitbombay.org (Bakul Shah) Date: Mon, 14 Dec 2020 18:57:06 -0800 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: References: <88E7F8CE-DC08-44AB-BF12-EFD4C5958950@iitbombay.org> Message-ID: <4E9347ED-A37E-435A-A1BE-194C6E693B00@iitbombay.org> On Dec 14, 2020, at 12:28 PM, Dave Horsfall wrote: > > On Wed, 9 Dec 2020, Bakul Shah wrote: > >> please don’t blame c++ on pascal folks. stroustrup had nothing to do with pascal. > > I certainly hope not; Pascal was meant to be a teaching language, not a production language. As for C++, well, what can I say? It should've been called C-- ... I liked C with classes though never had a chance to use it. You do know there was a C-- (designed by Simon Peyton Jones & Norman Ramsay) as a "portable assembly language" (even more so than C) as a target for HLL compilers. > You wrote your algorithm in Pascal, debugged it, and then rewrote it in your favourite language (in my case, ALGOL-W). Now why didn't Don Knuth think of that for TeX? From imp at bsdimp.com Tue Dec 15 13:05:21 2020 From: imp at bsdimp.com (Warner Losh) Date: Mon, 14 Dec 2020 20:05:21 -0700 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: <4E9347ED-A37E-435A-A1BE-194C6E693B00@iitbombay.org> References: <88E7F8CE-DC08-44AB-BF12-EFD4C5958950@iitbombay.org> <4E9347ED-A37E-435A-A1BE-194C6E693B00@iitbombay.org> Message-ID: On Mon, Dec 14, 2020 at 7:58 PM Bakul Shah wrote: > On Dec 14, 2020, at 12:28 PM, Dave Horsfall wrote: > > You wrote your algorithm in Pascal, debugged it, and then rewrote it in > your favourite language (in my case, ALGOL-W). > > Now why didn't Don Knuth think of that for TeX? It's by far not the only program that's translated from a pascal-oid into C before being compiled. The Moria game from back in the late 80s was originally written in Pascal and ported to the PC by using a Pascal to C compiler someone had written because it was easier than getting it to compile under Turbo Pascal or something. Though that may have been a one-shot deal. The code has since been rewritten two or three times... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.douglas.mcilroy at dartmouth.edu Tue Dec 15 21:45:44 2020 From: m.douglas.mcilroy at dartmouth.edu (M Douglas McIlroy) Date: Tue, 15 Dec 2020 06:45:44 -0500 Subject: [TUHS] Knuth and Pascal (was "Were cron and at ...") Message-ID: Off topic, but too much fun to pass up. >> You wrote your algorithm in Pascal, debugged it, and then rewrote it in your favourite language (in my case, ALGOL-W). > Now why didn't Don Knuth think of that for TeX? I'm glad he didn't. He might have written it in Mix. Knuth once said he didn't believe in higher-level languages. Of course he knew more about them than anybody else and was CACM's associate editor for the subject--like a minister who doesn't believe in God. Doug From toby at telegraphics.com.au Tue Dec 15 23:04:21 2020 From: toby at telegraphics.com.au (Toby Thain) Date: Tue, 15 Dec 2020 08:04:21 -0500 Subject: [TUHS] Knuth and Pascal (was "Were cron and at ...") In-Reply-To: References: Message-ID: On 2020-12-15 6:45 a.m., M Douglas McIlroy wrote: > Off topic, but too much fun to pass up. > >>> You wrote your algorithm in Pascal, debugged it, and then rewrote it in your favourite language (in my case, ALGOL-W). > >> Now why didn't Don Knuth think of that for TeX? He did even more than that, inventing literate programming and tools for it, so that he could write in a Pascal-like language enhanced according to his preferences and beliefs about program exposition to humans. Because the output of his tools was standard Pascal, Tex and METAFONT were easily and widely ported. --Toby > > I'm glad he didn't. He might have written it in Mix. Knuth once said > he didn't believe in higher-level languages. Of course he knew more > about them than anybody else and was CACM's associate editor for the > subject--like a minister who doesn't believe in God. > > Doug > From srbourne at gmail.com Wed Dec 16 02:02:19 2020 From: srbourne at gmail.com (srbourne) Date: Tue, 15 Dec 2020 11:02:19 -0500 Subject: [TUHS] sh and goto Message-ID: Message: 4 Date: Mon, 30 Nov 2020 19:59:18 -0800 (PST) From:jason-tuhs at shalott.net To:tuhs at minnie.tuhs.org Subject: Re: [TUHS] The UNIX Command Language (1976) Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Wed Dec 16 05:18:16 2020 From: bakul at iitbombay.org (Bakul Shah) Date: Tue, 15 Dec 2020 11:18:16 -0800 Subject: [TUHS] Knuth and Pascal (was "Were cron and at ...") In-Reply-To: References: Message-ID: <64006DF6-FBE1-4F0E-9C45-64A5280FED50@iitbombay.org> > On Dec 15, 2020, at 3:46 AM, M Douglas McIlroy wrote: > > Off topic, but too much fun to pass up. > >>> You wrote your algorithm in Pascal, debugged it, and then rewrote it in your favourite language (in my case, ALGOL-W). > >> Now why didn't Don Knuth think of that for TeX? > > I'm glad he didn't. He might have written it in Mix. Knuth once said > he didn't believe in higher-level languages. Of course he knew more > about them than anybody else and was CACM's associate editor for the > subject--like a minister who doesn't believe in God. > > Doug Did he actually say that? In this delightful interview https://conservancy.umn.edu/bitstream/handle/11299/107413/oh332dk.pdf in response to a question about were there any giant steps in CS, he says the idea of Structured Programming is a giant step but those are few and far between. A number of times he comments on structured programming (as opposed to HLLs). About Go To and SP: "It is like the zero population growth movement: The goal isn’t really to have zero population growth; the goal is to improve people’s quality of life. But they substitute a quantitative goal for the qualitative goal, and that’s like viewing structured programming as only a non-‘Go To’ type of a program, which is foolish, and I am sure Edsger didn’t mean it that way at all." He also mentions he wrote an Algol compiler for Burroughs during the summer of 1960. Knuth finished the first draft of what became TAOCP in 1966. Given that there were already many discussions about Algol X but no clarity and that he really did want people to understand what steps are needed and their cost, that is, get close to the computer, MIX made more sense (I'm glad it wasn't Fortran!). MIX wouldn't have made sense for TeX & METAFONT, which are in essence *recipes* made out of algorithmic ingredients and in effect he reimplemented these algorithms in Pascal. From athornton at gmail.com Wed Dec 16 05:27:07 2020 From: athornton at gmail.com (Adam Thornton) Date: Tue, 15 Dec 2020 12:27:07 -0700 Subject: [TUHS] Knuth and Pascal (was "Were cron and at ...") In-Reply-To: <64006DF6-FBE1-4F0E-9C45-64A5280FED50@iitbombay.org> References: <64006DF6-FBE1-4F0E-9C45-64A5280FED50@iitbombay.org> Message-ID: <24BAE60C-0E4B-4C8B-AA18-872DC055C56D@gmail.com> > On Dec 15, 2020, at 12:18 PM, Bakul Shah wrote: > >> On Dec 15, 2020, at 3:46 AM, M Douglas McIlroy wrote: >> >> >> I'm glad he didn't. He might have written it in Mix. Knuth once said >> he didn't believe in higher-level languages. Of course he knew more >> about them than anybody else and was CACM's associate editor for the >> subject--like a minister who doesn't believe in God. >> > > Did he actually say that? In this delightful interview > The strong impression I got from _Coders at Work_ is that Knuth, while perfectly capable in HLLs, prefers writing in MIX/MMIX simply because he finds it more fun than languages that provide you with prerolled abstractions. It’s a charming book, although I think the Knuth chapter is the best. Adam From kenbob at gmail.com Wed Dec 16 05:44:39 2020 From: kenbob at gmail.com (Ken Thompson) Date: Tue, 15 Dec 2020 11:44:39 -0800 Subject: [TUHS] sh and goto In-Reply-To: References: Message-ID: it was the right thing to do. wish i had thought of it. i was too busy saving bytes. On Tue, Dec 15, 2020 at 8:03 AM srbourne wrote: > Message: 4 > > Date: Mon, 30 Nov 2020 19:59:18 -0800 (PST) > From: jason-tuhs at shalott.net > To: tuhs at minnie.tuhs.org > Subject: Re: [TUHS] The UNIX Command Language (1976) > Message-ID: > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Wed Dec 16 09:27:28 2020 From: ggm at algebras.org (George Michaelson) Date: Wed, 16 Dec 2020 09:27:28 +1000 Subject: [TUHS] sh and goto In-Reply-To: References: Message-ID: HN has a story about a safe bash script template. Putting to one side the oxymoronic qualities of the sentence, the thing which stands out is the use of trap to a function on SIG -Which we all need, but often don't do. Thumping ^C repeatedly when things go unexpectedly wrong, is a fact of life. What do you want your script to do? Coding for the unexpected is just hard. Going into a script (or program) pre-thinking that you have to 'expect the unexpected' breaks the design imperative of planning for success. IF-THEN-ELSE doesn't always cope well with mental models of "do A,B,C but if Z happens get 2 dozen milk" (which leads to the joke about programmers shopping instructions with an IF clause in it) The trap thing in shell always confused me. What state am I "in" when I wind up in that trap? do variables exist (no: IIRC the var=value flow in a shellscript is lazy so the un-instantiated x=y inside an if expression you don't know was reached or not MAY not exist) has sub-job completed, (can trap pre-empt a wait statement? of course it can! what does it mean for children reaping... you do know the PID right?) None of this is rocket surgery. It goes to lawyer-like legalistic "one side of one cow in one field is black" reasoning -which for a program is probably not a bad thing, but it isn't very human(e) thinking for some people. Then enters ^T (the TOPS-10 inherited "what state am I in, in terms of CPU time and I/O") which somebody *else* is dealing with: the thing which called your shell instance.. trap is a setjmp/longjmp type outcome. You pop up in a call you didn't exactly "plan" for (well you did: you wrote it. But you don't know the entry state which led you there, unlike normal program flow) -well, it is.. because you get there. But you aren't going back to your normal logic flow anytime soon in any shellscript I saw. From m.douglas.mcilroy at dartmouth.edu Wed Dec 16 14:01:39 2020 From: m.douglas.mcilroy at dartmouth.edu (M Douglas McIlroy) Date: Tue, 15 Dec 2020 23:01:39 -0500 Subject: [TUHS] sh and goto Message-ID: > 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 From rich.salz at gmail.com Wed Dec 16 14:30:43 2020 From: rich.salz at gmail.com (Richard Salz) Date: Tue, 15 Dec 2020 23:30:43 -0500 Subject: [TUHS] sh and goto In-Reply-To: References: Message-ID: > trap is a setjmp/longjmp type outcome. You pop up in a call you didn't > exactly "plan" for (well you did: you wrote it. But you don't know the > entry state which led you there, unlike normal program flow) -well, it > is.. because you get there. I once won a Usenix contest for using /bin/sh to test your reflexes. trap "ls | wc ; exit 0" 0 1 2 3 15 ls * | wc -l echo "Type ^C; see how close you can make your number match" rm -rf * | wc -l kill -1 $$ # For those without "trap 0" -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Wed Dec 16 14:41:46 2020 From: ggm at algebras.org (George Michaelson) Date: Wed, 16 Dec 2020 14:41:46 +1000 Subject: [TUHS] sh and goto In-Reply-To: References: Message-ID: Great solution. Not entirely "side effect free.." On Wed, Dec 16, 2020 at 2:30 PM Richard Salz wrote: > > >> trap is a setjmp/longjmp type outcome. You pop up in a call you didn't >> exactly "plan" for (well you did: you wrote it. But you don't know the >> entry state which led you there, unlike normal program flow) -well, it >> is.. because you get there. > > > I once won a Usenix contest for using /bin/sh to test your reflexes. > > trap "ls | wc ; exit 0" 0 1 2 3 15 > ls * | wc -l > echo "Type ^C; see how close you can make your number match" > rm -rf * | wc -l > kill -1 $$ # For those without "trap 0" > From cowan at ccil.org Thu Dec 17 14:08:05 2020 From: cowan at ccil.org (John Cowan) Date: Wed, 16 Dec 2020 23:08:05 -0500 Subject: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: <7e66e5eb-6cea-5403-a2cc-e8d93f038e66@gmail.com> References: <88E7F8CE-DC08-44AB-BF12-EFD4C5958950@iitbombay.org> <7e66e5eb-6cea-5403-a2cc-e8d93f038e66@gmail.com> Message-ID: On Mon, Dec 14, 2020 at 7:00 PM Harald Arnesen wrote: > Now THATS's a sane language. I have never used it professionally (or > much at all), but I can see it's what Algol-687 should have been. > I studied A68 in detail with a friend of mine in 1976, and I've always admired it greatly. The van Wijngaarden two-level used in the original report was rather opaque, though the revised report was much more readable (and did not only the syntax and the static semantics, but the dynamic semantics as well). Only when I got a hold of an actual A68 textbook years later did I actually see a straight grammar of the language, which got me interested in the language again. Sometimes I wonder what would have happened if A68 had become the medium-level language of Unix, and Pascal had become the language of non-Unix, instead of both of them using C. (The four segment registers of the x86 mirror exactly the way Pascal pointers work: it is statically known whether a pointer points to the stack, the code, the data, or the heap segment.) John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org And it was said that ever after, if any man looked in that Stone, unless he had a great strength of will to turn it to other purpose, he saw only two aged hands withering in flame. --"The Pyre of Denethor" -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.douglas.mcilroy at dartmouth.edu Fri Dec 18 00:21:14 2020 From: m.douglas.mcilroy at dartmouth.edu (M Douglas McIlroy) Date: Thu, 17 Dec 2020 09:21:14 -0500 Subject: [TUHS] Algol 68 and Unix (was cron and at ...) Message-ID: > 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 From ron at ronnatalie.com Fri Dec 18 00:24:47 2020 From: ron at ronnatalie.com (Ronald Natalie) Date: Thu, 17 Dec 2020 09:24:47 -0500 Subject: [TUHS] Algol 68 and Unix (was cron and at ...) In-Reply-To: References: Message-ID: <0EA02917-243E-4612-9F7E-D370EE0A7C2E@ronnatalie.com> > On Dec 17, 2020, at 9:21 AM, M Douglas McIlroy wrote: > > 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. I was never so happy as when SVR2 came out and found that someone had “translated” the shell source code back into C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Dec 18 00:35:58 2020 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 17 Dec 2020 06:35:58 -0800 Subject: [TUHS] Algol 68 and Unix (was cron and at ...) In-Reply-To: <0EA02917-243E-4612-9F7E-D370EE0A7C2E@ronnatalie.com> References: <0EA02917-243E-4612-9F7E-D370EE0A7C2E@ronnatalie.com> Message-ID: <20201217143558.GD13268@mcvoy.com> On Thu, Dec 17, 2020 at 09:24:47AM -0500, Ronald Natalie wrote: > > > > On Dec 17, 2020, at 9:21 AM, M Douglas McIlroy wrote: > > > > 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. > > I was never so happy as when SVR2 came out and found that someone had ???translated??? the shell source code back into C. I sort of agree. The macro-ed ALGOL like syntax that Steve did was hard to deal with if you weren't on the ALGOL train (I was not, too young). So the C version was easier for me to understand. But it sort of lost something, I didn't really understand Steve's version, not at any deep level. But it made more sense, somehow, than the C version did. --lm From mike.ab3ap at gmail.com Fri Dec 18 00:44:52 2020 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Thu, 17 Dec 2020 09:44:52 -0500 Subject: [TUHS] Algol 68 and Unix (was cron and at ...) In-Reply-To: References: Message-ID: <39730a23-090d-0a03-a536-aa83d5f7dc6f@gmail.com> On 12/17/20 9:21 AM, M Douglas McIlroy wrote: > > ...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... By coincidence, fortune brought this up as I opened a terminal window: No proper program contains an indication which as an operator-applied occurrence identifies an operator-defining occurrence which as an indication-applied occurrence identifies an indication-defining occurrence different from the one identified by the given indication as an indication-applied occurrence. -- ALGOL 68 Report Yikes... Mike From iain at csp-partnership.co.uk Fri Dec 18 07:18:33 2020 From: iain at csp-partnership.co.uk (Dr Iain Maoileoin) Date: Thu, 17 Dec 2020 21:18:33 +0000 Subject: [TUHS] Algol 68 and Unix (was cron and at ...) In-Reply-To: <39730a23-090d-0a03-a536-aa83d5f7dc6f@gmail.com> References: <39730a23-090d-0a03-a536-aa83d5f7dc6f@gmail.com> Message-ID: > On 17 Dec 2020, at 14:44, Mike Markowski wrote: > > On 12/17/20 9:21 AM, M Douglas McIlroy wrote: >> ...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... > > By coincidence, fortune brought this up as I opened a terminal window: > > No proper program contains an indication which as an operator-applied occurrence identifies an operator-defining occurrence which as an indication-applied occurrence identifies an indication-defining occurrence different from the one identified by the given indication as an indication-applied occurrence. > -- ALGOL 68 Report Now that I understand ;-) > Yikes… But that bit I dont! ;-( > Mike We we taught Algol 68 R, running it on an ICL 1904S from 1st year onwards. The 1904 was a 24bit 6 bits per “byte” system. Handling upper and lower on the line printer was a lot of work! The mixture of language practical and theory helped cement both. Unix did not come along - for the uni - until a year or so later. A decent understanding of the Algol68 pointers, deref (auto or not), casts, array slices, garbage collection etc made moving to C fairly easy for most of the cohort. The fortune cooked has been a bad journalist and taken the sentence out of context. The previous 423 pages were essential reading. From cowan at ccil.org Fri Dec 18 15:06:41 2020 From: cowan at ccil.org (John Cowan) Date: Fri, 18 Dec 2020 00:06:41 -0500 Subject: [TUHS] Algol 68 and Unix (was cron and at ...) In-Reply-To: References: <39730a23-090d-0a03-a536-aa83d5f7dc6f@gmail.com> Message-ID: On Thu, Dec 17, 2020 at 6:02 PM Dr Iain Maoileoin < iain at csp-partnership.co.uk> wrote: > The fortune cooked has been a bad journalist and taken the sentence out of > context. The previous 423 pages were essential reading. Well, I'll go with Lindsey's [?] remark about how you can't understand any part of the Report until you understand all of it. However, without the typography it's a lot harder to follow. -------------- next part -------------- An HTML attachment was scrubbed... URL: From coppero1237 at gmail.com Fri Dec 18 22:28:09 2020 From: coppero1237 at gmail.com (Tyler Adams) Date: Fri, 18 Dec 2020 14:28:09 +0200 Subject: [TUHS] History of the UNIX Beard Message-ID: 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 with majestic manes. And, to make the question a bit more meta, what's the history of the joke of the "UNIX beard"? Tyler -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Fri Dec 18 23:56:00 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 18 Dec 2020 08:56:00 -0500 (EST) Subject: [TUHS] History of the UNIX Beard Message-ID: <20201218135600.2674218C08B@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 From coppero1237 at gmail.com Fri Dec 18 23:58:04 2020 From: coppero1237 at gmail.com (Tyler Adams) Date: Fri, 18 Dec 2020 15:58:04 +0200 Subject: [TUHS] History of the UNIX Beard In-Reply-To: <20201218135600.2674218C08B@mercury.lcs.mit.edu> References: <20201218135600.2674218C08B@mercury.lcs.mit.edu> Message-ID: I imagine there's relatives like the programmer beard, but googling "UNIX beard" returns some examples where it seems to be a thing. http://www.usenix.org.uk/content/unix_beards.html https://www.urbandictionary.com/define.php?term=Unix%20beard https://www.reddit.com/r/linux/comments/4nt38v/how_many_of_you_have_a_unix_beard/ https://www.atlasobscura.com/articles/why-do-hackers-love-beards-so-much subtitle: " Decoding the “Unix beard” at this year’s DefCon. https://pthree.org/2009/11/01/get-your-unix-beard-on/ Tyler On Fri, Dec 18, 2020 at 3:56 PM Noel Chiappa wrote: > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikke.karlsson at gmail.com Sat Dec 19 00:00:42 2020 From: nikke.karlsson at gmail.com (Niklas Karlsson) Date: Fri, 18 Dec 2020 15:00:42 +0100 Subject: [TUHS] History of the UNIX Beard In-Reply-To: References: <20201218135600.2674218C08B@mercury.lcs.mit.edu> Message-ID: Unfortunately, I can't grow a proper UNIX beard. The most I can manage is a rather scraggly goatee, so I go for clean-shaven or a bit stubbly these days. Niklas Den fre 18 dec. 2020 kl 14:59 skrev Tyler Adams : > I imagine there's relatives like the programmer beard, but googling "UNIX > beard" returns some examples where it seems to be a thing. > http://www.usenix.org.uk/content/unix_beards.html > https://www.urbandictionary.com/define.php?term=Unix%20beard > > https://www.reddit.com/r/linux/comments/4nt38v/how_many_of_you_have_a_unix_beard/ > https://www.atlasobscura.com/articles/why-do-hackers-love-beards-so-much subtitle: > " Decoding the “Unix beard” at this year’s DefCon. > https://pthree.org/2009/11/01/get-your-unix-beard-on/ > > Tyler > > > On Fri, Dec 18, 2020 at 3:56 PM Noel Chiappa > wrote: > >> > 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 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.paulsen at firemail.de Sat Dec 19 16:43:08 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Sat, 19 Dec 2020 07:43:08 +0100 Subject: [TUHS] History of the UNIX Beard In-Reply-To: References: Message-ID: >the UNIX beard please check out: http://www.usenix.org.uk/content/unix_beards.html From wkt at tuhs.org Wed Dec 23 08:43:06 2020 From: wkt at tuhs.org (Warren Toomey) Date: Wed, 23 Dec 2020 08:43:06 +1000 Subject: [TUHS] ksh88 source code? Message-ID: <20201222224306.GA28478@minnie.tuhs.org> Hi all, I received an e-mail looking for the ksh-88 source code. A quick search for it on-line doesn't reveal it. Does anybody have a copy? Cheers, Warren Original e-mail: I recently built a PiDP11 and have been enjoying going back in time to 2.11BSD.. I was at UC Davis in the the early 1980's and we had a few PDP-11/70's running 2.8/2.9 BSD. Back then we reached out to David Korn and he sent us the source for KSH -- this would have been in 1985ish if I remember, and we compiled it for 2.9 & 4.1BSD, Xenix, and some other variants that used K&R C. It may have been what was later called ksh88. I wish I still had the files from then.. I was wondering if you might know if there's an older version like this or one that's been ported for 2.11BSD? Many thanks, Joe From clemc at ccc.com Wed Dec 23 09:01:41 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 22 Dec 2020 18:01:41 -0500 Subject: [TUHS] ksh88 source code? In-Reply-To: <20201222224306.GA28478@minnie.tuhs.org> References: <20201222224306.GA28478@minnie.tuhs.org> Message-ID: If you were outside of AT&T, it was distributed via AT&T Summit's 'toolchest' thingy (and were as a single license to join it and but separate fees for each tool - if you wanted sub-license there was a secondary process which I forget the details -- I remember used it so we could make ksh, mk and ditroff standard on the MASSCOMP and later Stellar boxes). My memory is that the toolchest was created before SVR4, I want to say SVR2 (maybe as late as SVR3) timeframe. Its origin is it was a way to get some of the tools that came from different teams around the labs out without having to including them in a full release. Earlier, Brian's ditroff and Dennis's compiler were licensed (together) but using the original licensing/distribution scheme. As tools like ksh and mk came on the scene, Otis Wilson asked a number of us customers what to do. The toolchest was born from that discussion. It was cool in the after you ordered, you go a uucp address to 'pull' the bits for your site from the toolchest. No tapes were written - which is why I think find things now may be hard. That said, I've not found a repository of the toolchest stuff as I'm not so sure ATT really released all of it in the sense of the basic system itself. For instance, the support for the JERQ (including the games) were all in the toolchest and last spring a few of us were looking for the GBACA sources. I'm not sure if they were found. Basically, you need to find someone that had had a toolchest license for that specific tool and still has the bits somewhere. Clem On Tue, Dec 22, 2020 at 5:44 PM Warren Toomey wrote: > Hi all, I received an e-mail looking for the ksh-88 source code. A quick > search for it on-line doesn't reveal it. Does anybody have a copy? > > Cheers, Warren > > Original e-mail: > I recently built a PiDP11 and have been enjoying going back in time > to 2.11BSD.. I was at UC Davis in the the early 1980's and we had > a few PDP-11/70's running 2.8/2.9 BSD. Back then we reached out to > David Korn and he sent us the source for KSH -- this would have been > in 1985ish if I remember, and we compiled it for 2.9 & 4.1BSD, Xenix, > and some other variants that used K&R C. It may have been what was > later called ksh88. I wish I still had the files from then.. > > I was wondering if you might know if there's an older version like this > or one that's been ported for 2.11BSD? > Many thanks, > Joe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpl.jpl at gmail.com Wed Dec 23 11:29:49 2020 From: jpl.jpl at gmail.com (John P. Linderman) Date: Tue, 22 Dec 2020 20:29:49 -0500 Subject: [TUHS] ksh88 source code? In-Reply-To: References: <20201222224306.GA28478@minnie.tuhs.org> Message-ID: Does it have to be ksh88? https://github.com/att/ast has ksh93 source. -- jpl On Tue, Dec 22, 2020 at 6:03 PM Clem Cole wrote: > If you were outside of AT&T, it was distributed via AT&T Summit's > 'toolchest' thingy (and were as a single license to join it and but > separate fees for each tool - if you wanted sub-license there was a > secondary process which I forget the details -- I remember used it so we > could make ksh, mk and ditroff standard on the MASSCOMP and later Stellar > boxes). > > My memory is that the toolchest was created before SVR4, I want to say > SVR2 (maybe as late as SVR3) timeframe. Its origin is it was a way to get > some of the tools that came from different teams around the labs out > without having to including them in a full release. Earlier, Brian's > ditroff and Dennis's compiler were licensed (together) but using the > original licensing/distribution scheme. As tools like ksh and mk came on > the scene, Otis Wilson asked a number of us customers what to do. The > toolchest was born from that discussion. It was cool in the after you > ordered, you go a uucp address to 'pull' the bits for your site from the > toolchest. No tapes were written - which is why I think find things now > may be hard. > > That said, I've not found a repository of the toolchest stuff as I'm not > so sure ATT really released all of it in the sense of the basic system > itself. For instance, the support for the JERQ (including the games) were > all in the toolchest and last spring a few of us were looking for the GBACA > sources. I'm not sure if they were found. > > Basically, you need to find someone that had had a toolchest license for > that specific tool and still has the bits somewhere. > > Clem > > On Tue, Dec 22, 2020 at 5:44 PM Warren Toomey wrote: > >> Hi all, I received an e-mail looking for the ksh-88 source code. A quick >> search for it on-line doesn't reveal it. Does anybody have a copy? >> >> Cheers, Warren >> >> Original e-mail: >> I recently built a PiDP11 and have been enjoying going back in time >> to 2.11BSD.. I was at UC Davis in the the early 1980's and we had >> a few PDP-11/70's running 2.8/2.9 BSD. Back then we reached out to >> David Korn and he sent us the source for KSH -- this would have been >> in 1985ish if I remember, and we compiled it for 2.9 & 4.1BSD, Xenix, >> and some other variants that used K&R C. It may have been what was >> later called ksh88. I wish I still had the files from then.. >> >> I was wondering if you might know if there's an older version like this >> or one that's been ported for 2.11BSD? >> Many thanks, >> Joe >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rp at servium.ch Wed Dec 23 13:30:17 2020 From: rp at servium.ch (Rico Pajarola) Date: Tue, 22 Dec 2020 19:30:17 -0800 Subject: [TUHS] ksh88 source code? In-Reply-To: <20201222224306.GA28478@minnie.tuhs.org> References: <20201222224306.GA28478@minnie.tuhs.org> Message-ID: there's a plain ksh88 in here: bitsavers/bits/HP/HP_9000/HPUX_9/9.10_S300_Source_Product.cpio.gz The open sourced Solaris 8 tarball contains ksh88i I'm sure there's more ;) But what a shame that the 1985ish ksh got lost. On Tue, Dec 22, 2020 at 2:44 PM Warren Toomey wrote: > Hi all, I received an e-mail looking for the ksh-88 source code. A quick > search for it on-line doesn't reveal it. Does anybody have a copy? > > Cheers, Warren > > Original e-mail: > I recently built a PiDP11 and have been enjoying going back in time > to 2.11BSD.. I was at UC Davis in the the early 1980's and we had > a few PDP-11/70's running 2.8/2.9 BSD. Back then we reached out to > David Korn and he sent us the source for KSH -- this would have been > in 1985ish if I remember, and we compiled it for 2.9 & 4.1BSD, Xenix, > and some other variants that used K&R C. It may have been what was > later called ksh88. I wish I still had the files from then.. > > I was wondering if you might know if there's an older version like this > or one that's been ported for 2.11BSD? > Many thanks, > Joe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sj at sdf.org Wed Dec 23 15:46:13 2020 From: sj at sdf.org (Scot Jenkins) Date: Wed, 23 Dec 2020 00:46:13 -0500 Subject: [TUHS] ksh88 source code? In-Reply-To: <20201222224306.GA28478@minnie.tuhs.org> References: <20201222224306.GA28478@minnie.tuhs.org> Message-ID: <202012230546.0BN5kDwe028815@sdf.org> Warren Toomey wrote: > Hi all, I received an e-mail looking for the ksh-88 source code. A quick > search for it on-line doesn't reveal it. Does anybody have a copy? https://archive.org/details/ATTUNIXSystemVRelease4Version2 has source for several releases. click "show all" on the right under "download options", the file sysvr4.tar.bz2 has source for ksh88: from cmd/ksh/sh/msg.c: msg.c: MSG e_version = "\n@(#)Version M-11/16/88d\0\n"; I think this was for x86 PCs. I haven't tried to build it. The date on the files is Jan 25 1993. scot From arnold at skeeve.com Wed Dec 23 16:56:10 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 22 Dec 2020 23:56:10 -0700 Subject: [TUHS] ksh88 source code? In-Reply-To: <20201222224306.GA28478@minnie.tuhs.org> References: <20201222224306.GA28478@minnie.tuhs.org> Message-ID: <202012230656.0BN6uA56026336@freefriends.org> I have ksh88f that I got from the Toolchest. My files are dated April 6, 1991. If anyone wants it, please let me know. Arnold Warren Toomey wrote: > Hi all, I received an e-mail looking for the ksh-88 source code. A quick > search for it on-line doesn't reveal it. Does anybody have a copy? > > Cheers, Warren > > Original e-mail: > I recently built a PiDP11 and have been enjoying going back in time > to 2.11BSD.. I was at UC Davis in the the early 1980's and we had > a few PDP-11/70's running 2.8/2.9 BSD. Back then we reached out to > David Korn and he sent us the source for KSH -- this would have been > in 1985ish if I remember, and we compiled it for 2.9 & 4.1BSD, Xenix, > and some other variants that used K&R C. It may have been what was > later called ksh88. I wish I still had the files from then.. > > I was wondering if you might know if there's an older version like this > or one that's been ported for 2.11BSD? > Many thanks, > Joe From efton.collins at gmail.com Wed Dec 23 17:19:13 2020 From: efton.collins at gmail.com (Efton Collins) Date: Wed, 23 Dec 2020 01:19:13 -0600 Subject: [TUHS] ksh88 source code? In-Reply-To: <202012230546.0BN5kDwe028815@sdf.org> References: <20201222224306.GA28478@minnie.tuhs.org> <202012230546.0BN5kDwe028815@sdf.org> Message-ID: here is a link to a ksh version that seems to predate ksh88, msg.c says "Version 06/03/86a": https://github.com/weiss/original-bsd/tree/master/local/toolchest/ksh I found the link at the bottom of this interesting page: https://www.in-ulm.de/~mascheck/various/shells/ksh_versions.html and this link contains a surprising amount of information on many shell versions released over the years - https://www.in-ulm.de/~mascheck/various/shells On 12/22/20, Scot Jenkins via TUHS wrote: > Warren Toomey wrote: > >> Hi all, I received an e-mail looking for the ksh-88 source code. A quick >> search for it on-line doesn't reveal it. Does anybody have a copy? > > > https://archive.org/details/ATTUNIXSystemVRelease4Version2 > has source for several releases. > > click "show all" on the right under "download options", > the file sysvr4.tar.bz2 has source for ksh88: > > from cmd/ksh/sh/msg.c: > msg.c: MSG e_version = "\n@(#)Version M-11/16/88d\0\n"; > > I think this was for x86 PCs. I haven't tried to build it. > The date on the files is Jan 25 1993. > > scot > From thomas.paulsen at firemail.de Wed Dec 23 19:03:33 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Wed, 23 Dec 2020 10:03:33 +0100 Subject: [TUHS] ksh88 source code? In-Reply-To: References: <20201222224306.GA28478@minnie.tuhs.org> Message-ID: <319932a40cb405f26e3dfed7309cc19b@firemail.de> An HTML attachment was scrubbed... URL: From rp at servium.ch Wed Dec 23 19:14:06 2020 From: rp at servium.ch (Rico Pajarola) Date: Wed, 23 Dec 2020 01:14:06 -0800 Subject: [TUHS] ksh88 source code? In-Reply-To: <319932a40cb405f26e3dfed7309cc19b@firemail.de> References: <20201222224306.GA28478@minnie.tuhs.org> <319932a40cb405f26e3dfed7309cc19b@firemail.de> Message-ID: On Wed, Dec 23, 2020 at 1:03 AM Thomas Paulsen wrote: > you mean:­ > http://www.bitsavers.org/bits/HP/HP_9000/HPUX_9/9.10_S300_Source_Product.cpio.gz yes copy paste is hard ;) > there's a plain ksh88 in here: > bitsavers/bits/HP/HP_9000/HPUX_9/9.10_S300_Source_Product.cpio.gz > > The open sourced Solaris 8 tarball contains ksh88i > > I'm sure there's more ;) > > But what a shame that the 1985ish ksh got lost. > > > > > *Gesendet mit Firemail.de - Freemail* -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Thu Dec 24 05:32:57 2020 From: rich.salz at gmail.com (Richard Salz) Date: Wed, 23 Dec 2020 14:32:57 -0500 Subject: [TUHS] Style and diction commands available? Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Dec 24 06:25:26 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 23 Dec 2020 15:25:26 -0500 Subject: [TUHS] Style and diction commands available? In-Reply-To: References: Message-ID: Sorry, I should have mentioned those too. I thought you were interested in something closer to the historical version. Truth be known, I have Gnu's version 1.11 installed on my Mac (as part of brew), however but I think they are 13 years old not 3 :-) On Wed, Dec 23, 2020 at 2:33 PM Richard Salz wrote: > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Thu Dec 24 07:35:08 2020 From: rich.salz at gmail.com (Richard Salz) Date: Wed, 23 Dec 2020 16:35:08 -0500 Subject: [TUHS] Style and diction commands available? In-Reply-To: References: Message-ID: My goal was to find something to catch simple errors in IETF RFC's. And yeah, a typo on 13 vs 3 :) I've run it over a few documents, not sure if it's worth adding an xml/markdown filter to handle input "better" or not. On Wed, Dec 23, 2020 at 3:25 PM Clem Cole wrote: > Sorry, I should have mentioned those too. I thought you were interested > in something closer to the historical version. Truth be known, I have > Gnu's version 1.11 installed on my Mac (as part of brew), however but I > think they are 13 years old not 3 :-) > > On Wed, Dec 23, 2020 at 2:33 PM Richard Salz wrote: > >> 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. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Thu Dec 24 08:57:23 2020 From: wkt at tuhs.org (Warren Toomey) Date: Thu, 24 Dec 2020 08:57:23 +1000 Subject: [TUHS] ksh88 source code? In-Reply-To: References: <20201222224306.GA28478@minnie.tuhs.org> Message-ID: <20201223225723.GD29181@minnie.tuhs.org> On Tue, Dec 22, 2020 at 08:29:49PM -0500, John P. Linderman wrote: > Does it have to be ksh88? [1]https://github.com/att/ast has ksh93 > source. -- jpl I think the original poster couldn't get ksh93 to compile on 2.11BSD. Thanks though, Warren From wkt at tuhs.org Thu Dec 24 09:28:18 2020 From: wkt at tuhs.org (Warren Toomey) Date: Thu, 24 Dec 2020 09:28:18 +1000 Subject: [TUHS] Fwd: For the archives: UNIX/24V for the Harris /6 Docs In-Reply-To: References: Message-ID: <749c2984-9b35-d427-6e65-fa2ce821b544@tuhs.org> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Dec 24 09:38:25 2020 From: imp at bsdimp.com (Warner Losh) Date: Wed, 23 Dec 2020 16:38:25 -0700 Subject: [TUHS] Fwd: For the archives: UNIX/24V for the Harris /6 Docs In-Reply-To: <749c2984-9b35-d427-6e65-fa2ce821b544@tuhs.org> References: <749c2984-9b35-d427-6e65-fa2ce821b544@tuhs.org> Message-ID: Are the sources for this work available? Warner On Wed, Dec 23, 2020, 4:29 PM Warren Toomey wrote: > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Thu Dec 24 09:30:31 2020 From: aek at bitsavers.org (Al Kossow) Date: Wed, 23 Dec 2020 15:30:31 -0800 Subject: [TUHS] Fwd: For the archives: UNIX/24V for the Harris /6 Docs In-Reply-To: <749c2984-9b35-d427-6e65-fa2ce821b544@tuhs.org> References: <749c2984-9b35-d427-6e65-fa2ce821b544@tuhs.org> Message-ID: <436c5308-c9e4-8091-d10d-61c7a11210fb@bitsavers.org> On 12/23/20 3:28 PM, Warren Toomey wrote: > 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/ RIP Bill It would be nice if this port could be found, though I'm not very hopeful There isn't a lot of Harris 24-bit software out there. From jnc at mercury.lcs.mit.edu Thu Dec 24 11:36:18 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 23 Dec 2020 20:36:18 -0500 (EST) Subject: [TUHS] Fwd: For the archives: UNIX/24V for the Harris /6 Docs Message-ID: <20201224013618.DE09B18C0AA@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 From lm at mcvoy.com Fri Dec 25 01:03:49 2020 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 24 Dec 2020 07:03:49 -0800 Subject: [TUHS] Fwd: For the archives: UNIX/24V for the Harris /6 Docs In-Reply-To: <20201224013618.DE09B18C0AA@mercury.lcs.mit.edu> References: <20201224013618.DE09B18C0AA@mercury.lcs.mit.edu> Message-ID: <20201224150349.GP4048@mcvoy.com> On Wed, Dec 23, 2020 at 08:36:18PM -0500, Noel Chiappa wrote: > > 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 ()"). A sad message. I "worked" with Bill, fought with Bill is more like it, but we were on the same side, we both wanted what was best for Sun's customers, we just didn't always agree on what that was. As much as I fought with him, there were many times I wanted to quit and what kept me there was I didn't want Bill to be fighting alone. He was a great guy. From: Bill Shannon Subject: public static final void goodbye() { /**NORETURN*/ }* Date: May 30, 2020 at 11:51:04 PM EDT To: Bill Shannon A year and a half ago I was diagnosed with a rare abdominal tumor that turned out to be cancer. ??For almost a year we believed surgery had removed it completely, but such was not to be the case. ??I've spent 6 months fighting a losing cause with chemo, and it's now clear that fight is coming to an end. I've worked with so many amazing people, on so many interesting projects, and made so many invaluable friendships over the years that it will be impossible to remember who all to acknowledge and thank for helping making my life so incredible. I started at Sun (as employee #11) by bringing SunOS to life. ??Just as wild success was within reach, we stretched a little too far and signed a deal with AT&T. ??That set us back almost 5 years, but at least I have the "black edition" of Solaris signed by Eric Schmidt - "I'm Sorry". Next it was time to move on to learn about window systems, desktop applications, and industry consortiums in the form of CDE. CDE was moving much too slowly and in 1996 a new opportunity presented itself - Java. ??We tried a Java machine, a JavaOS, and a Java desktop environment - Hotjava Views. ??None of that really panned out until Java found its home as an application server environment, first named J2EE and then named Java EE. ??I was recruited as leader of this new effort, which has subsequently been given a new name and new leadership - Jakarta EE at the Eclipse Foundation. When I started work at Sun I was sure I was going to be working on Unix forever. ??Clearly Unix will continue for long time, and I believe Java has at least as much runway as Unix. ??Best of luck to all of you working on these technologies going forward. ??I'm glad I got to live through the non-event of Y2K; I'm disappointed I don't get to do the same for Y2038K. This message started with a list of a few of the people who made a big impact on my career at Sun and Oracle. ??But the more I added to the list, the more I knew the list would never end. ??I decided to just fill in the first and last items on the list, trusting that you'll know where to fill in the rest. Bill Joy started it all. ??An intense week with Bill while I was working at DEC gave me a new appreciation for binary patching, and soon an offer to join Sun! ??Sun pretty much defined my career, and my life, for quite some time. ??With three exceptions, it was the best thing that ever happened to me. Ed Bratt helped hold our team together through some very tough spots, but most important to me was as a good friend helping me navigate and providing support through these final days at Oracle. In addition, there's the uncountable good people, coworkers and not, that I've considered my very closest, dearest, and most trustworthy friends. If you've ever shared a glass of wine at my house, you know who you are. There's especially the Thursday lunch bunch and the Sunday night dinner group. ??How would I have ever gotten by without you? And finally there's those three exceptions. ??There're my daughters Kim (28; building Pok??mon Go! for Niantic), Amy (24; finishing her BS in Anthropology at the University of Oregon), and Karen, my wife of 40 years and without whom I would not be who I am today. ??While they're all very strong people, they will all benefit from your continued help and friendship. Obviously there's considerable uncertainty with predicting these sort of things, and I've already beaten the odds several times, but let's just say it feels like time is running out more quickly. ??If there's any last minute things you'd like to say or hear, now is the time. I love you all and can't imagine a world without all of us in it. Bill From rminnich at gmail.com Tue Dec 29 10:30:47 2020 From: rminnich at gmail.com (ron minnich) Date: Mon, 28 Dec 2020 16:30:47 -0800 Subject: [TUHS] Which years saw the introduction of (1) #! and (2) symbolic links Message-ID: I think I remember but want to ask the experts. From ron at ronnatalie.com Tue Dec 29 11:04:54 2020 From: ron at ronnatalie.com (Ron Natalie) Date: Tue, 29 Dec 2020 01:04:54 +0000 Subject: [TUHS] Which years saw the introduction of (1) #! and (2) symbolic links In-Reply-To: References: Message-ID: Symlinks came out in 4.1BSD (1981), I think. #! came out in 4. (1980 ) ------ Original Message ------ From: "ron minnich" To: "TUHS main list" Sent: 12/28/2020 7:30:47 PM Subject: [TUHS] Which years saw the introduction of (1) #! and (2) symbolic links >I think I remember but want to ask the experts. From clemc at ccc.com Tue Dec 29 12:07:46 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 28 Dec 2020 21:07:46 -0500 Subject: [TUHS] Which years saw the introduction of (1) #! and (2) symbolic links In-Reply-To: References: Message-ID: FYI: Dennis did symlinks before Joy did and it was 4.1a where they first show up in the BSD stream As for shebang, the idiom was recognized by the shell in user space in 1.0 BSD, when the precursor to cshell (the Berkeley shell) was released - but it took a while to make it into the kernel as recognized look-a-side to be more automatic. My >>memory<< is we had it in the 2BSD release, but it might not have been added until 3BSD - look at the exec.c code in the BSD kernels which frankly I'm too lazy tonight to do myself. ᐧ On Mon, Dec 28, 2020 at 8:11 PM Ron Natalie wrote: > Symlinks came out in 4.1BSD (1981), I think. > #! came out in 4. (1980 > ) > ------ Original Message ------ > From: "ron minnich" > To: "TUHS main list" > Sent: 12/28/2020 7:30:47 PM > Subject: [TUHS] Which years saw the introduction of (1) #! and (2) > symbolic links > > >I think I remember but want to ask the experts. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From reed at reedmedia.net Tue Dec 29 11:41:24 2020 From: reed at reedmedia.net (Jeremy C. Reed) Date: Mon, 28 Dec 2020 19:41:24 -0600 (CST) Subject: [TUHS] Which years saw the introduction of (1) #! and (2) symbolic links In-Reply-To: References: Message-ID: (Just first question here ...) Early BSD shells could look at first bytes (0404) to indicate was a pascal object to run the Berkeley pascal interpreter. When csh was introduced, the csh would run the other shell /bin/sh if the first character was not a # pound. So csh used the single # as magic to run the script with csh. The # was a comment for csh, make, and awk (but not for standard sh which could use a : colon for the comment). Have a look at top of 4BSD's /usr/src/sys/newsys/sys1.c below. This code is not in v7 nor 32V. >From uucp Thu Jan 10 01:37:58 1980 >From dmr Thu Jan 10 04:25:49 1980 remote from research The system has been changed so that if a file being executed begins with the magic characters #! , the rest of the line is understood to be the name of an interpreter for the executed file. Previously (and in fact still) the shell did much of this job; it automatically executed itself on a text file with executable mode when the text file's name was typed as a command. Putting the facility into the system gives the following benefits. 1) It makes shell scripts more like real executable files, because they can be the subject of 'exec.' 2) If you do a 'ps' while such a command is running, its real name appears instead of 'sh'. Likewise, accounting is done on the basis of the real name. 3) Shell scripts can be set-user-ID. 4) It is simpler to have alternate shells available; e.g. if you like the Berkeley csh there is no question about which shell is to interpret a file. 5) It will allow other interpreters to fit in more smoothly. To take advantage of this wonderful opportunity, put #! /bin/sh at the left margin of the first line of your shell scripts. Blanks after ! are OK. Use a complete pathname (no search is done). At the moment the whole line is restricted to 16 characters but this limit will be raised. >From uucp Thu Jan 10 01:37:49 1980 >From dmr Thu Jan 10 04:23:53 1980 remote from research From rminnich at gmail.com Tue Dec 29 15:03:31 2020 From: rminnich at gmail.com (ron minnich) Date: Mon, 28 Dec 2020 21:03:31 -0800 Subject: [TUHS] Which years saw the introduction of (1) #! and (2) symbolic links In-Reply-To: References: Message-ID: reason I asked was my memory was #! in 1978 or so. But that's now sounding like I compressed time a bit. On Mon, Dec 28, 2020 at 6:08 PM Clem Cole wrote: > FYI: Dennis did symlinks before Joy did and it was 4.1a where they first > show up in the BSD stream > As for shebang, the idiom was recognized by the shell in user space in 1.0 > BSD, when the precursor to cshell (the Berkeley shell) was released - but > it took a while to make it into the kernel as recognized look-a-side to be > more automatic. My >>memory<< is we had it in the 2BSD release, but it > might not have been added until 3BSD - look at the exec.c code in the BSD > kernels which frankly I'm too lazy tonight to do myself. > ᐧ > > On Mon, Dec 28, 2020 at 8:11 PM Ron Natalie wrote: > >> Symlinks came out in 4.1BSD (1981), I think. >> #! came out in 4. (1980 >> ) >> ------ Original Message ------ >> From: "ron minnich" >> To: "TUHS main list" >> Sent: 12/28/2020 7:30:47 PM >> Subject: [TUHS] Which years saw the introduction of (1) #! and (2) >> symbolic links >> >> >I think I remember but want to ask the experts. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Dec 31 03:15:46 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 30 Dec 2020 12:15:46 -0500 Subject: [TUHS] Which years saw the introduction of (1) #! and (2) symbolic links In-Reply-To: References: Message-ID: On Tue, Dec 29, 2020 at 12:03 AM ron minnich wrote: > reason I asked was my memory was #! in 1978 or so. But that's now sounding > like I compressed time a bit. > Sounds a little early for my memory for the kernel, but about right for the support using the shells. I would have thought we talked about the idea at the Summer '79 USENIX and later Dennis implemented a patch for Research Unix which it looks like he released it in early 1980. But if I'm not getting my dates wrong, that should have been before 3BSD was released for the Vax; which syncs with my memory that it was in 3BSD. Due to address space issues on the 11, add features to the kernel that we could do in userspace, was often the preferred place. I just don't remember if Joy had it in the 2BSD kernel before Dennis added it to the research kernel, but I do remember it was in shells @ UCB as Jeremy said much earlier. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Dec 31 17:19:39 2020 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 31 Dec 2020 18:19:39 +1100 (EST) Subject: [TUHS] The 2038 bug... Message-ID: As the new year is about to kick in (down-under anyway), it got me to thinking (always dangerous): how many here will be around for it to pick up the pieces that are no doubt still lying around? I'll be about the ripe old age of 85, so I may be around to see the Imminent Death of the Internet (Film at 11). 2100? Forget it... Too bad, as "Revolt in 2100 (?)" is one of my favourite Heinlein books. Others? -- Dave From nikke.karlsson at gmail.com Thu Dec 31 17:24:42 2020 From: nikke.karlsson at gmail.com (Niklas Karlsson) Date: Thu, 31 Dec 2020 08:24:42 +0100 Subject: [TUHS] The 2038 bug... In-Reply-To: References: Message-ID: I'll be a mere 58, so not even retired yet. I fear it will be a very interesting time, in the "May you live in interesting times" sense. Niklas Den tors 31 dec. 2020 kl 08:21 skrev Dave Horsfall : > As the new year is about to kick in (down-under anyway), it got me to > thinking (always dangerous): how many here will be around for it to pick > up the pieces that are no doubt still lying around? > > I'll be about the ripe old age of 85, so I may be around to see the > Imminent Death of the Internet (Film at 11). > > 2100? Forget it... Too bad, as "Revolt in 2100 (?)" is one of my > favourite Heinlein books. > > Others? > > -- Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Thu Dec 31 18:10:13 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 31 Dec 2020 01:10:13 -0700 Subject: [TUHS] The 2038 bug... In-Reply-To: References: Message-ID: <202012310810.0BV8ADZ3027195@freefriends.org> Will there be that many 32 bit systems left by then? time_t these days tends to be 64 bits, and I think at least the Linux file systems store them that way. Microsoft counts time from January 1, 1980, so that buys them until 2048. :-) I'll be (G-d willing) 79 then; I hope around, but I also hope not overly involved with computers. :-) Arnold Niklas Karlsson wrote: > I'll be a mere 58, so not even retired yet. I fear it will be a very > interesting time, in the "May you live in interesting times" sense. > > Niklas > > Den tors 31 dec. 2020 kl 08:21 skrev Dave Horsfall : > > > As the new year is about to kick in (down-under anyway), it got me to > > thinking (always dangerous): how many here will be around for it to pick > > up the pieces that are no doubt still lying around? > > > > I'll be about the ripe old age of 85, so I may be around to see the > > Imminent Death of the Internet (Film at 11). > > > > 2100? Forget it... Too bad, as "Revolt in 2100 (?)" is one of my > > favourite Heinlein books. > > > > Others? > > > > -- Dave > >