TUHS

tuhs@tuhs.org

47 participants
6503 discussions

by Rudi Blom

>From output of 'what' on /bin/sh in SCO UNIX 3.2V4.2 - spname.c 23.2 91/02/21 Cheers, uncle rubl >Date: Sat, 09 Jan 2021 03:39:16 -05 >From: Norman Wilson <norman(a)oclsc.org> >To: tuhs(a)tuhs.org >Subject: Re: [TUHS] Question >Message-ID: <1610181560.23999.for-standards-violators(a)oclsc.org> > >Rob Pike, re the spelling corrector in V8 and later Research >versions of sh: > > That was done by Tom Duff, I believe before he came to Bell Labs. I might > have brought the idea with me from Toronto. > >Very likely, since you left it behind at Caltech as well; it was >in sh on cithep (a hostname meaningless to many but rob will remember) >when I arrived in 1980. > >It was in the version of p you left behind there as well. > >I can confirm that spname remained in the shell through V10 >(it's still in my copy), but it seems to have disappeared from p. > >Norman Wilson >Toronto ON

4 years, 4 months

Re: [TUHS] Question

by Norman Wilson

Rob Pike, re the spelling corrector in V8 and later Research versions of sh: > That was done by Tom Duff, I believe before he came to Bell Labs. I might > have brought the idea with me from Toronto. Very likely, since you left it behind at Caltech as well; it was in sh on cithep (a hostname meaningless to many but rob will remember) when I arrived in 1980. It was in the version of p you left behind there as well. I can confirm that spname remained in the shell through V10 (it's still in my copy), but it seems to have disappeared from p. Norman Wilson Toronto ON

4 years, 4 months

Re: [TUHS] The 2038 bug...

by Norman Wilson

Warner Losh: Less ugly would be to declare time_t to be unsigned instead of signed... It would break less code... Making time_t 64 bits also breaks code, even if you declare you don't care about binary compat since many older apps know time_t is 32-bits. === I remember chatting in 1998 with a consultant who worked with clients in the financial industry. They still used 32-bit systems at the time, and had already converted critical programs (I don't know whether that included parts of libc or they had their own conversion routines) to make time_t unsigned. It mattered early to those folks because of 40-year bonds. That suggests to me that the financial-services world may have a head start on the 2038 problem, but I fear many others are still lagging behind. 64 bits will help but not as much for embedded systems and legacy stuff. Us hobbyists will doubtless have fun too, as we already do (ask Warren) when running the earliest existing UNIX images, in which times are stored in sixtieths of a second. Norman Wilson Toronto ON

4 years, 4 months

Re: [TUHS] Question

by Rudi Blom

The spell check in 'cd' commands I remember from SCO UNIX 3.2 The 'sh' manual page has Spelling checker When using cd(C) the shell checks spelling. For example, if you change to a different directory using cd and misspell the directory name, the shell responds with an alternative spelling of an existing directory. Enter ``y'' and press <Return> (or just press <Return>) to change to the offered directory. If the offered spelling is incorrect, enter ``n'', then retype the command line. In this example the sh(C) response is boldfaced: $ cd /usr/spol/uucp cd /usr/spool/uucp?y ok Cheers, uncle rubl >Date: Mon, 04 Jan 2021 02:08:09 -0700 >From: arnold(a)skeeve.com >To: m.douglas.mcilroy(a)dartmouth.edu, egbegb2(a)gmail.com >Cc: tuhs(a)tuhs.org >Subject: Re: [TUHS] Question >Message-ID: <202101040908.104989TF022830(a)freefriends.org> >Content-Type: text/plain; charset=us-ascii > >The spelling corrector in the shell rings vague bell. I think >it's in the 8th or 9th edition Bourne shell. You should be able to >find those in the archives. > >Geoff Collyer has a modern port of the V9 shell at >http://www.collyer.net/who/geoff/v9sh.tar. > >HTH, .> >Arnold

4 years, 4 months

Re: [TUHS] Question

by M Douglas McIlroy

> I was a BTL person for 8 years between 1976 and 1984. During > that time there was a spelling corrector that was better than > anything I see today. There was a concept of "spelling distance" > that corrected a whole bunch of stuff that even today cannot be > corrected. > Who in that era worked on spelling correction at BTL. I was at > Columbus BTL (1976-1979) and Whippany BTL (1979-1984). Peter Nelson made an interface to spell(1) that showed putative errors in context. I believe it could suggest corrections. I remember the project; I installed hooks for it in spell(1). I don't remember the date, but it would probably not have been early enough for you to have used it in Columbus. If there's a chance that Peter's program is the one you remember and you'd like to get in touch with him, I can give you his email address. Doug

4 years, 4 months

The "File Store" at mid 1970's Murray Hill

by Paul Ruizendaal

Sandy Fraser was kind enough to share some papers from his archive that give further background to early networking at Bell Labs. One of these is about the “File Store”. For context I refer to an article that Sandy wrote back in 1975 and describes the network setup at Murray Hill at that time: https://drive.google.com/file/d/1_kg4CEsbGucsU8-jxi0ptfUdsznWcKWm/view?usp=… In the figure and legenda at the bottom of page 52/53, the "File Store" is item 10. The File Store paper itself is (temporarily) here: https://drive.google.com/file/d/1AhLmjJcHXFtfoIUlfvl0bzbB0zSPzpSq/view?usp=… The paper has a very interesting introduction: “Five machines currently use the file store. Three of them use it as if were a peripheral device not part of their main backing store. In these cases there exists programs to transmit complete files between the user’s machine and the file store." This was known and Noel Chiappa found the source for the main transfer program “nfs” (this program is also mentioned in Doug McIllroy’s manual compendium): https://chiselapp.com/user/pnr/repository/Spider/tree?ci=tip The introduction continues: “In the other two cases the file store is treated as an extension of the user machine’s backing store. Once a user has opened a file his program does reads, writes, and seeks without being aware of the file’s actual location.” This -- to me at least -- is a new fact and as such it would predate various other projects for a distributed Unix file system (the paper is dated December 1974). Unfortunately, the paper is short on how the integration was achieved. On one hand the work may have been related to "Peripheral Unix” as developed by Heinz Lycklama (https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/TM-…) at the same time -- the memos are dated just a month apart. In essence the approach is to forward system calls over the network 1). Another possibility is that it worked much like the 1979 “RIDE” system (https://www.computer.org/csdl/proceedings-article/cmpsac/1979/00762533/12Om…) Here there is a modified C library that recognises certain path names and maps these to file server calls. A third possibility is that it was a precursor to the work on distributed Unix by Luderer et al. in 1980/81 (https://dl.acm.org/doi/abs/10.1145/1067627.806604) Here file system calls are redirected at the kernel level using the concept of a remote/forwarding inode. The File Store paper mentions that the server is a modified Unix. At first glance it would seem that the modifications are modest, with the file system partly rewritten to account for storage usage, and an automatic backup feature added. I am much interested in any recollections, insights and materials about these topics. Many thanks in advance, Paul Note 1) The tech report on the “high speed serial loop” (the Weller loop) has not surfaced yet, but the document for the Glance terminal gives a quick, high level overview on page 3/4: https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/TM-… The recent 516 documents include a detailed description of how it worked: https://www.tuhs.org/Archive/Documentation/Other/516-TSS/516-10-11-12-Ring-…

4 years, 4 months

Question

by Ed Bradford

I was a BTL person for 8 years between 1976 and 1984. During that time there was a spelling corrector that was better than anything I see today. There was a concept of "spelling distance" that corrected a whole bunch of stuff that even today cannot be corrected. Who in that era worked on spelling correction at BTL. I was at Columbus BTL (1976-1979) and Whippany BTL (1979-1984). Who ever did that stuff should patent it and sell it. Today there is nothing like it. -- Advice is judged by results, not by intentions. Cicero

4 years, 4 months

Reviving the Research Unix speak(6) program

by Diomidis Spinellis

Happy new year to all! Over the holidays I found some time to port the recovered version of speak(6) to modern Unix systems and make its output compatible with the espeak system. The resulting sound is barely intelligible. I assume this is due to the imperfect matching between the speak and espeak phonemes. The process's details are available at https://www.spinellis.gr/blog/20210102#tu and the code at https://github.com/dspinellis/speak. Diomidis

4 years, 4 months

Re: [TUHS] G.W.R. Luderer

by Brian Walden

His autobiography, Go West, Young German! states it is luderer at asu.edu -- but that was published a decade ago. Paul Ruizendaal (pnr at planet.nl) wrote: > > I am looking for some more background on the 1980/81 "S/F-Unix" system. > > Gottfried W. R. Luderer, H. Che, J. P. Haggerty, Peter A. Kirslis, W. T. Marshall: > A Distributed UNIX System Based on a Virtual Circuit Switch. SOSP 1981: 160-168 > I have that paper, and Bill Marshall was kind enough to provide a lot of info. I think that Gottfried Luderer may have some further background, in particular on how this work relates to earlier distributed file system projects at Bell Labs. > > Would anybody have a current e-mail address for him? > > Paul

4 years, 4 months

G.W.R. Luderer

by Paul Ruizendaal

I am looking for some more background on the 1980/81 "S/F-Unix" system. Gottfried W. R. Luderer, H. Che, J. P. Haggerty, Peter A. Kirslis, W. T. Marshall: A Distributed UNIX System Based on a Virtual Circuit Switch. SOSP 1981: 160-168 I have that paper, and Bill Marshall was kind enough to provide a lot of info. I think that Gottfried Luderer may have some further background, in particular on how this work relates to earlier distributed file system projects at Bell Labs. Would anybody have a current e-mail address for him? Paul

4 years, 4 months

Re: [TUHS] The 2038 bug...

by M Douglas McIlroy

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

4 years, 4 months

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

by ron minnich

I think I remember but want to ask the experts.

4 years, 4 months

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

by jnc＠mercury.lcs.mit.edu

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

4 years, 5 months

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

by Warren Toomey

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

4 years, 5 months

Re: [TUHS] Style and diction commands available?

by Richard Salz

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

4 years, 5 months

Re: [TUHS] History of the UNIX Beard

by jnc＠mercury.lcs.mit.edu

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

4 years, 5 months

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

by M Douglas McIlroy

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

4 years, 5 months

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

by M Douglas McIlroy

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

4 years, 5 months

sh and goto

by srbourne

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

4 years, 5 months

sh and goto

by M Douglas McIlroy

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

4 years, 5 months

Knuth and Pascal (was "Were cron and at ...")

by M Douglas McIlroy

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

4 years, 5 months

Re: [TUHS] Were cron and at done at the same time? Or one before the other?

by jnc＠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

4 years, 5 months

Happy birthday, Ada Lovelace and JFO!

by Dave Horsfall

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

4 years, 5 months

Re: [TUHS] Were cron and at done at the same time? Or one before the other?

by jnc＠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

4 years, 5 months

Re: [TUHS] Were cron and at done at the same time? Or one before the other?

by John Foust

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

4 years, 5 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS