TUHS

tuhs@tuhs.org

16 participants
6536 discussions

by jnc＠mercury.lcs.mit.edu

> From: Henry Bent > What was the hardware configuration of the 11/45 that Research used to > implement early UNIX? .. I have found numerous references to it being > an early production 11/45, and I assume that it had an RK05, but I > cannot find any details about things like memory size and other > peripherals. A good source is the Ken+Dennis picture: https://www.bell-labs.com/usr/dmr/www/picture.html and the caption which Dennis wrote for it. The image is not quite definitive, because there are two machines in that bank of racks: a PDP-11/20, and a PDP-11/45 (mostly hidden behind the right-hand Teletype), and it's not possible to say which of the two machines the various peripherals are attached to. But it seems to have had two RK03's (and an RK11 somewhere to drive them) and an RF11 (no idea how many RS11 drives it had at that point),; a TU56 (and a TC11 somewhere to drive that), and a PC05 (with PC11 controller boards). (There are pages for all these things here: https://gunkies.org/wiki/Category:UNIBUS_Peripherals which include links to the DEC documentation on them.) I'm doing more searching, through documents I recall having additional crumbs; let me go ahead and send this, and there will be a lengthy addendum shortly. Noel

1 year, 12 months

Some old DECtapes from Dennis Ritchie

by Warren Toomey

All, way back when, Dennis sent me some DECtape images to look after. I've put some of them in the Unix Archive (the s1 and s2 tapes) as they contained Unix source code or binaries. The others I kept aside as they didn't contain Unix code, or they were potentially sensitive. Anyway, Angelo Papenhoff asked for any old tapes from the Labs that might contain fragments of B source code or B binaries. I passed the extra tapes on to him, and he has found some very interesting nuggets from the time period when B -> NB -> C. So, to help provide the context around Angelo's work, I've decided to put all the tapes that Dennis gave me here: https://www.tuhs.org/Archive/Applications/Dennis_Tapes/ Cheers, Warren

1 year, 12 months

Re: Bell COBOL Environment?

by Paul Ruizendaal

> Reading through [1], there are documents offered by AT&T for the "Level II COBOL" system, which some further research indicates is a product from Convergent (same folks as the UNIX PC.) There's also the LPI-COBOL which appears to be a Language Processor Inc. product. Ryan-McFarland comes to mind: in my recollection they were the leading Cobol on small machines in the early 80’s. Ryan-McFarland’s predecessor company Digitek was contracted to do the PL/I compiler for Multics, but failed. It seems they later did Bell Labs PL/I (says https://en.wikipedia.org/wiki/Digitek) I think they did a Unix version of their Cobol in the mid/late 80’s as well. A few years ago I tried to find out more about RM-Cobol as it existed in the late 70’s and early 80’s, but with little success. As a product it survived till the present day under the ownership of Micro-Focus and most web mentions are for more recent versions. It would seem to me that compilers on machines with small memories and word sizes in the 60’s, 70’s and even 80’s tended to compile to a virtual machine / intermediate code -- sometimes with the option to compile to native from there. Think BCPL and o-code, Pascal and p-code, the Amsterdam Compiler Kit and m-code, the Microsoft “revenue bomb” p-code C compiler, etc. According to the above Wikipedia article RM-Cobol used the same approach. I did once see the source for another 80’s Cobol compiler and it compiled to a virtual machine with 60-bit words. By the way, I loved the recent posts on B and NB. THUS at its best!

2 years

Bell COBOL Environment?

by segaloco

Reading through [1], there are documents offered by AT&T for the "Level II COBOL" system, which some further research indicates is a product from Convergent (same folks as the UNIX PC.) There's also the LPI-COBOL which appears to be a Language Processor Inc. product. Are these the earliest AT&T endorsed COBOL solutions for UNIX or were there other efforts either promoted by Bell or even perhaps developed locally that were in any use before this version? Or otherwise is there any other family of ubiquitous UNIX COBOL tools that was in use in the 70s and early 80s, before the timeframe of this document? Additionally is anyone aware of any surviving code or binaries of either of these or other, earlier efforts at COBOL on UNIX? I have no goal for this information in mind yet, but just gathering details at this point. Thanks all! - Matt G. [1] - http://bitsavers.org/pdf/att/000-111_ATT_Documentation_Guide_Nov87.pdf

2 years

B compiler restored

by Angelo Papenhoff

So there's been quite a bit of talk about B recently (mostly from my side) and right now I feel that I've reach an interesting enough milestone to warrant a separate thread for this here. First of all, I want to stress that this is still WIP, but everything can be found here now: https://github.com/aap/b/tree/master/unix1_bdir In this repo you will find the following: - bc and ba that can build themselves (I've included .s files so everything can be bootstrapped easily). - libb and bilib in source form from object/library and binary files of the s2 tape - brt1 and brt2 restored from binary files of the s2 tape - olibb, obilib and obrt1, older versions of the above - a version of ba that does not generate threaded code but an interpreted code more like the pdp-7 code. ken told me such a thing existed at one point and indeed it is the only way to fit the compiler into 8kb/4kw - an implementation of this interpreted code. With this bc and ba fit into 8kb Note I have only tested this under apout so far. The version I used [1] needed two tweaks, but see my README. With this I was able to build the recently reversed B programs [2] and produce exact matches to the originals (modulo assembler differences). In that process I found a few mistakes I made, now the programs are exact. I want to thank everyone who was of help in this endeavour in one way or another: Ken Thompson, Phil Budne, Robert Swierczek, Steve Johnson, Warren Toomey What's left to do now is to actually run this under UNIX v1 proper, preferably even on a real machine. I've been too lazy for that so far. Also there are inaccuracies and unknowns in the compiler and assembler. Right now the intermediate code is a binary code that's easy to generate and to parse, but if I understood ken correctly the intermediate code was more like something the PDP-7 assembler could deal with. I'm also rather unsure how to handle the conditional ?: operator. The printf.o file shows that it produces labels that are in line with all the other labels. Now the C compiler uses labels starting at L10000 for the ones generated in the second pass. So it *feels* like the conditional should be generated by bc directly and not by ba but this leads to other problems, which I won't go into detail now. Finally the code should probably be a bit closer to the C compiler than it currently is. Cheers, Angelo [1] https://github.com/philbudne/pdp11-B/tree/pb/tools/apout [2] http://squoze.net/B/programs/

2 years

OSDI/ATC?

by Dan Cross

Is anyone else at OSDI/ATC this year? Any interest in a BoF? - Dan C.

2 years

Re: Who stated that the power of Unix stems from the wise choice of a few design principles rather than the endless accumulation of special cases

by jnc＠mercury.lcs.mit.edu

> From: Diomidis Spinellis <dds(a)aueb.gr> > I seem to recall reading that the power of Unix stems from the wise > choice of a few design principles rather than the endless accumulation > of special cases. However, I cannot find where this is stated. I think you're thinking of something in the CACM paper: https://www.bell-labs.com/usr/dmr/www/cacm.html "The success of Unix lies not so much in new inventions but rather in the full exploitation of a carefully selected set of fertile ideas" Noel

2 years

Who stated that the power of Unix stems from the wise choice of a few design principles rather than the endless accumulation of special cases

by Diomidis Spinellis

I seem to recall reading that the power of Unix stems from the wise choice of a few design principles rather than the endless accumulation of special cases. However, I cannot find where this is stated. I tried a Google web and a Google Scholar search using the terms "unix endless accumulation special cases", and I also asked ChatGPT for a publication associated with this phrase. I also searched for "special" in D.M.Ritchie's "The Evolution of the Unix Time-sharing System" and "The UNIX Time-sharing System A Retrospective". (Amazingly, both have several parts that still highly relevant.) Can anyone help? Am I misremembering something?

2 years

PSA: Several 1983 SysV Documents on eBay

by segaloco

Howdy folks, I just wanted to pass on word that there is currently a stack of 1983 System V documents on eBay, here's a link to the User's Manual: https://www.ebay.com/itm/225659365754 The same seller has these documents available in their shop (as well as a bunch of other old computing documents and magazines): - User's Manual - Administrator's Manual - Error Message Manual - Operator's Guide - Graphics Guide - Transition Aids - Release Description So not the whole lot, but a nice spread nonetheless. I've already got all of these and they're already all scanned in some fashion or another, or I'd have scooped em up already. Anywho, figured that might pique folks' curiosity. The pricing is very agreeable might I add, sometimes I see single volumes from this set going for over $100. - Matt G.

2 years

Lions commentary

by Rich Salz

I have a copy of Lions's "A Commentary on the UNIX Operating System" It is an n-th generation photocopy that I've had for some number of decades. It also has the source code, as I guess all of those copies did back in the day. I could just recycle the paper -- it's yellowed with age -- but I'd rather pay it forward and ship it to someone who promises to make copies for others who want it. This is also on bitsavers, so you're only doing this to preserve the sense of history in passing photocopies around. I'll take bids on how many copies you'll provide. I'll post the winning bid (without their address), so that the community can pressureXXXXXX ensure they meet their commitment. I'll send it out by the end of the week. I will give preference to US/Canada domestic addresses since that is easier for me. How much preference is left to my discretion. :) I hope this doesn't make me sound like a jerk; it's intended to be lighthearted community service.

2 years

Re: symbols in eqnchar

by Douglas McIlroy

> What is the name of the mathematic symbols Here are some readings, not exactly names incl (used with partial orderings) is included in, or is less than |> is not greater than |< is not less than <wig >wig wig is approximately, or asymptotically approaches ~wig is approximately Doug

2 years

Re: Jerq menuhit/mhit

by norman＠oclsc.org

I had an experience similar to Tom London's: To: alice!rob Subject: you've spoiled me I can't believe it. I'm sitting here at home in front of my 2621, and I can't work. Damn it. I've got to get a blit at home. When I left Bell Labs, I had an X11 workstation at work, but only a simple terminal at home. Having used a Jerqblit5620 for years at both work and home, I found it incredibly limiting. After a year or so I came across a reseller who had a lot of off-lease 5620s for sale cheap (like USD 150 or so each). I asked around the university I now worked at, found a handful of other people who wanted in, and then a local small company who did System V system-administration consulting who wanted some for themselves, and were willing to handle all the paperwork. All that allowed us to negotiate the price down even more. In the end I bought six, of which I think four are still working, though I haven't turned any of them on for years. None of the Unixes I used at the time came with 5620 support, but the protocol for the basic window system built into the ROM was well-documented and I managed to roll my own host support. I also managed to cobble up my own binary-loading tools sufficient to get sam working (I forget how I compiled the binary for the terminal); that was rather more work, but it was worth it to be able to have sam and multiple windows from home, even though it was the ROM OS and therefore mpx rather than mux. I remember porting my version of the host code to Ultrix, SunOS 4, and IRIX. My workplace at the time had a little bit of VAX/VMS around. I didn't use that much but wanted to try porting my host code to VMS as well. VMS had had a C compiler for some years and some sort of pseudo-terminal for a shorter time, so it ought to have been possible. I didn't get around to it before we finally left VMS behind in the dustbin of history. I wish I'd found time to do it, just to show that there really was nothing Unix-specific about the idea or the implementation. It's just a multiplexing protocol; it needs no kernel support except that needed to run a command-line session not attached to a physical terminal, and networking has long since made that available on any competent OS. Norman Wilson Toronto ON

2 years

Jerq menuhit/mhit

by Noel Hunt

The standard routine for drawing menus on the jerq was 'menuhit'. Items in the menu were centered, and the menu was scrollable when a certain threshold number of items was reached, and in addition, when the mouse pointer was in the top (bottom) item of the menu and it was possible to scroll in the appropriate direction, the menu was scrolled up or down 1 line. The structure associated with these menus is 'Menu'. There was however another menu-drawing routine, 'mhit', the menus drawn by this being hierarchical, the structure NMenu, which no longer contained text strings but an array of NItems. NMenus also had provision for 'help' text to be displayed, a simple string displayed on the screen, when button 1 was pressed while an entry in the menu was selected. The earliest version in the Eight Edition jerq code, also has one function in the NMenu structure which is called when the mouse pointer invokes a hierarchical menu. By Ninth Edition this has been expanded, with 3 functions, one as above, one invoked when an item is selected ('hit') and one when a hierarchical menu is exited. In the jerq code directories, under 'lib/jj', is a small 'ms' document, 'A Library of Goo for the 5620', which lists routines available in the library, and their authors. Andrew Hume is listed as the author of 'mhit'. Are there examples of code using these three menu functions ('dfn', 'hfn', 'bfn')? There seems to have been little interest in hierarchical menus at the labs, their use was quite limited. I found a program in the Tenth Edition archive, 'bubble' (which seems to be a program for displaying the three-dimensional structure of molecules) which uses them. 'samuel' made heavy use of them, including use of the 'hit' function, and Tom Cargill used basically the same code in 'pads' wherein the routine was called 'scripthit'. The plain 'menuhit' survived into Plan9, but as far as I know, it is only used by 'sam'.

2 years

Bell Labs CSTRs

by arnold＠skeeve.com

Available at https://www.skeeve.com/bell-labs-cstrs.tar.gz Warren and Brantley and anyone else, feel free to retrieve. I have two sets - both are in the tarball so there are undoubtedly duplications. If someone else can curate them into single canonical set that'd be helpful, I just don't have the time right now. Enjoy, Arnold

2 years

Bell Labs CSTRs

by Douglas McIlroy

> once you've got M3 and M4, you've got a naming convention; I'd > think it a safe bet that there was an M5 that was an internal > experiment, and that M6 was simply the next in line M6 came first, created by Andy Hall as a portability tool for Altran. I always assumed the name echoed Ken Knowlton's L6 (BelL Labs low level list language, with a superscript 6). I seem to recall that M6 was endowed with a very labored acronym. Doug

2 years

troff doc discovery

by Steve Simon

2 years

Trying to date "A Supplemental Document For Awk"

by Aharon Robbins

Hi All. Attached is "A Supplemental Document For Awk". This circulated on USENET in the 80s. My copy is dated January 18, 1989, but I'm sure it's older than that. One clue is the reference to the 4.2 BSD manual, and 4.3 came out already in 1986 or so. Does anyone else have a copy of this with perhaps an older date? As far as I can tell from a short search, the author is no longer living. If someone knows better and can provide contact info for him, that'd be great. In the meantime, Warren, do you want to add it to the archives? Thanks! Arnold

2 years

C Btrees

by Noel Hunt

There is a little known suite of programs, written by Peter Weinberger, found as 'btree', or 'cbt', in the archives for Eighth and Tenth Edition. The code in the Eighth Edition archive seems to be the earliest, and has fewer utilities than available in the Tenth Edition code. A search through files shows that it was used by 'road', 'weather' and 'apnews'. There is an ms file, 'memo', describing the programs, amongst the code, but an appendix seems to be missing. If anyone knows about this or where it might be I'd like to get my hands on it. 'Memo' itself is interesting because it's the only troff document I've seen amongst the reseach papers (excluding Christopher Van Wyk's own paper of course) that uses 'ideal', in this case, for drawing a picture depicting B-tree structure.

2 years

Late 70's UNIX Stream Differences from V6

by segaloco

Hello, I'd like to share some analysis from my recent Sixth Edition pass of my mandiff repository. For the V5-V6 diff, I opted for a branching approach, starting with a last universal common ancestor (which isn't quite right [1]). I compared each set of changes with the MERT0, PWB 1.0, CB-UNIX 2.3, 32V, and to a lesser extent V7 and System III manuals attempting to suss out the spiderweb of changes between them all. I created a series of branches representing last common changes between groups of branches as well. This has resulted in a littering of merge commits in the repository, but a banana's gonna have a peel. A few important points about document genealogy here: - The MERT0 manual, in the introduction, denotes descent from the USG Program Generic 3 manual. Furthermore, there is a listing of which pages would be replaced, which also serves as a key to which pages should be PG3 original text. However, the hs(IV) and ht(IV) pages make reference to specific MERT pages, so I question the veracity of this list. In any case, for the purposes of this analysis, much may extrapolate to USG PG3 as well. More study is needed. - The CB-UNIX manual currently available is Edition 2.3. In studying the numbering system for CB, I've found that this represents Release 2, Issue 3, as in the kernel there are references to releases, not editions. The clue is in one of the manpages somewhere, I don't recollect as of this typing where, but that'll come back around soon enough. The manual itself appears to be from a binder that was once a CB-UNIX 2.1 binder and had select pages replaced. There are some bits and pieces of 2.1 pages that were otherwise slated to be replaced, alluding to things like the /etc/lines file in common with PG3. In any case I've prioritized 2.1 changes over 2.3 changes where they can be determined, but like PG3, no complete picture can be determined of 2.1 from available documentation. For each of the branches, the following number of files in total reflect V5-V6 changes which aren't incorporated: - 32V: 7 - PWB: 15 - MERT0: 46 Of these MERT0 has the greatest number of items lacking research's upstream changes from late '74-early '75. Among them: - Has a V5-ish bas(I), no rc(I) (ratfor) at all - The group system is not present, newgrp(I), group(V), chgrp(VIII), etc. are nowhere to be found - nice(I) has no priority argument, simply sets a "low priority" - TTYs are still referred to as "teletypes" instead of "typewriters" in many places - there are 10 TTYs max so many commands don't reflect adjustments for two-digit IDs (ps(I) in particular is quite different, very V5) - retains the lpr print command (which shows up again in 32V and System III) - additionally, according to the replacement page list, PG3 retained the fed and form editing programs - Program Generic may not have had a man(I) page, as the one here is a MERT0 addition, hard to say CB tragically needs to be remerged, found as I was typing this up the system call section got an errant merge with V6 changes that shouldn't be there. Needless to say there is much in section II of the CB manual that leans more V5-ish than V6-ish. PWB differs in minor ways. The differences can be found in this list https://gitlab.com/segaloco/mandiff/-/merge_requests?scope=all&state=closed Each of the obviously labeled, closed merges represents a snapshot diff of the particular branch in question. As stated, the CB branch currently is in dire straits, I'm going to work that up again sometime in the future, but I should be able to use this to produce diff-able reproductions of the MERT0 and CB-UNIX 2.3 manual sources for this repository, as well as any other materials that may pop up. - Matt G. [1] - This pass I did not take good notes on such matters, but there are a few pages I'll anecdotally say reflect contents predating V5 sprinkled amongst the various manuals. I will consult with previous diffs when questions arise on in-depth analysis of the non-research changes in the branches. In any case the historical record already confirms CB-UNIX at the very least branched off quite early.

2 years

Software written in B

by Sebastien F4GRX

Hello everyone, this is my first post on this list. After looking at the archives for this mailing list, I have seen that the B language has been discussed several times already. After viewing Ken Thompson's interview by Brian Kernighan at VCF East 2019, I became interested in the B language, as it seemed full-featured for system programming, close to C, and simple enough to write a parser for it without a code generation tool. So for fun and self-education, I am now writing a (or yet another) B compiler, in C, after reading Jack Crenshaw's "Let's build a compiler" documentation ( https://compilers.iecc.com/crenshaw/ ) Here it is: https://git.sr.ht/~f4grx/bpars It is now starting to generate code for the 68hc11 8-bit platform. It can also generate C code. I have written some test programs, found some B examples, but I thought it would be great to use my compiler with actual B software. Of course, B was a "transition" language, that did not have a continued use as soon as it evolved into C. so if any software remains, it will be quite hard to find. And here is my question, is any of you aware of original B source code archives? or are in touch with people that would know? In particular, I read on this document written by Dennis Ritchie: https://www.bell-labs.com/usr/dmr/www/chist.html > After the TMG version of B was working, Thompson rewrote B in itself (a bootstrapping step). I have also read that the YACC tool was initially written in B. There might be other historical B sources that I am not aware of. Do you know if any of this code has survived to this day? Where could I find more information about this? Thank you very much, Sebastien Lorquet (F4GRX)

2 years

1981 Bell System Brochure and Price List

by segaloco

Spent some time this afternoon scanning and included a couple of those 1981 marketing documents I relayed some prices from in a previous email: https://archive.org/details/bell-system-software-brochure-1981 https://archive.org/details/bell-system-commercial-software-fees-1981 The cover of the former came out a bit rough. The stock photo is very fine stippling and my scanner just couldn't cut it. In any case, the first is a series of one-page summaries of various software offerings by the Bell System and the second is a price sheet not unlike https://www.bell-labs.com/usr/dmr/www/licenses/pricelist84.pdf but earlier. The larger brochure also includes software offerings for Honeywell and IBM systems as well as some portable components. - Matt G.

2 years

4.3BSD User Contributed Software Volume?

by segaloco

Hello, I've come across something in a bookshelf up at the local university that I have thus far been unsuccessful at locating online. It's a binder amongst other 4.3BSD binders like the reference manuals and supplementary documents but this one is labeled "User Contributed Software (UCS)". I can't find any of these in the doc folder of the 4.3BSD copies in the archive nor can I find a scan of the originals. There is an overview at the start listing the following packages: B, X, ansi (VAX tape tools), apl, bib, courier, cpm, dipress, dsh, emacs, enet, help, hyper, icon, jove, kermit, mh, mkmf, mmdf, news, notes, npl00, patch, path alias, rcs, rn, spms, sumacc, sunrpc, tac, tools, umodem, and xns. There are a preponderance of man pages as well as some focused papers for B, SPMS, the Icon programming language, and MMDFII. I didn't scribble down more notes before heading home because I figured this was something I'd find on page one of an internet search, but thus far have had no luck. If I don't turn up a digital copy soon I might just have to make another trip up there soon with my flatbed scanner. In any case I left a note too hoping whoever the curator of that bookshelf is (it was in some club room) might have the scoop on those binders, if they're left over from some long gone 4.3BSD installation in the EE/CS department and if they might have some siblings in other bookshelves nearby. - Matt G.

2 years

Re: undiagnosed pic error

by Douglas McIlroy

There may be a simple generic way to correct pic's habit of accepting any set of object modifiers on any object, but obeying only a compatible subset. Pic already collects a bit vector of modifier types attached to the current object. If that were extended with a few more bits that designate the object types, the size, B, of the bit vector would be about 35--an easy fit in one 64-bit word. Then a BxB bit matrix could record both modifier/modifier incompatibilities and object/modifier incompatibilities. The collected bit vector needs to be tested against the matrix once per object definition. It seems to be harder to catch duplication of modifiers, requiring extra code at all points where bits are set. Nevertheless, this kind of error also merits detection. Some questions Does anybody think the issue is not worth addressing? Is there a better scheme than that suggested above? Is the scheme adequate? It would not, for example, catch a three-way incompatibility that does not entail any pairwise incompatibility, should such an incompatibility exist. Any other thoughts? Doug

2 years

WECo UNIX 3B5 User's Manual Found

by segaloco

Good day, I've just received in the mail a UNIX System User Reference Manual for the 3B5 computer. It has a few differences with other documentation around it. As usual with an initial expository message, lots of info here, mostly so it'll get in the archive and on the record. So first off, I can't find a version reference in this thing. It is branded as "UNIX System" consistent with the branding nomenclature in the System V era, but I can't actually find the term "System V" anywhere thus far. However, a high level view implies relative parity with the initial release of System V. There are some areas where nomenclature is closer in character to the Release 5.0 manual, for instance, the "basinf" section in the intro refers to the user guide as "UNIX User Guide" rather than "UNIX System User's Guide" which is found in later System V stuff. In fact, this minor reference may point to some branching in the documentation between 4.x and SVR2 as I have the following in various manuals (prior to 4.1 i.e. 3.0/SysIII the reference is still directly to UNIX For Beginners, not a guide): - Release 4.1 - "UNIX User's Guide" - Release 5.0 - "UNIX User's Guide" - Release 5.0 BTL - "UNIX User's Guide" - System V - "UNIX System User's Guide" - System V 3B5 - "UNIX User Guide" - System V R2 BTL - "UNIX System User Guide" - System V DEC (1984) - "UNIX System User Guide" - System V R2 (1986 Manuals) - "UNIX System User's Guide" So SysV adds "System" to what was in Release 5.0, this carries through to conventional SVR2. The 3B5 version, however, drops the apostrophe and 's' that were in the pre-SysV nomenclature but doesn't add "System". Then even more confusing the SVR2 BTL copy appears to bear some lineage from this as it also has the dropped apostrophe and 's' but includes "System". Strange. Even stranger is I decided to take a peek at SVR2 docs from 1984, they lack the apostrophe and 's', but later SVR2 material from 1986 restores it. I wonder if this implies the 3B5 branch was started in the 5.0 days, diverged a bit, and then was only partially recombined with System V before release, although on the flip side, this manual *does* include the edit, ex, and vi manpages which were not printed in time for the System V manual run (as they are included with a separate documentation package instead.) This tracks with the BTL 5.0 having edit, ex, vi, and termcap present from Holmdel, the BTL manual got the pages early. All that to say, there are things in this manual that aren't yet in published System V manuals at the time, but there are things in this manual that have since been altered by the time of the formal System V documentation, pointing to an earlier branch point and then ongoing cross-talk after that. Included are references to a "3B Computer Network" and a few utilities associated. There are a few other pages too I didn't see in other contemporary public manuals, in total: - dcon(1) - Spawns a shell on a remote system via a DATAKIT circuit - logdir(1) - Returns the home directory field from /etc/passwd, this is in the BTL versions, I don't see it in public SysV though - ncp(1) - Copies files over the DATAKIT network - nisend(1) - Copies files over the "3B Computer Local Network" - nistat(1) - Query the status of said network - nitable(1) - Display the configuration table of said network - niupdate(1) - Update said configuration table - nkill(1) - Kill but using process names instead of IDs, but doesn't define process names, be it argv[0], the name of the image file, etc... - rexec(1) - Executes commands over a DATAKIT network - rl(1) - Login remotely over the 3B Computer Network (distinct from dcon being DATAKIT remote logins) This appears to be uucp-derived (specifically cu(1)) - dkdial(3) - Dials a DATAKIT connection - boothdr(4) - 3B5 only, provides the contents of <sys/boothdr.h> which supports storing parts of master(4), via mkboot(1M), in "a driver object file" to be used with "the self-config boot". Section 6 is mentioned in the intro but then omitted from the rest of the manual, so nothing to compare there. Also keeping with the documentation changes at the time, this does not include Sections 1M, 7, nor 8, as those are presumably in an accompanying Administrator's Reference Manual. That is another thing pegging this as System V rather than SVR2, by SVR2 they had further divided from two to three manuals, splitting the user manual into Sections 1 and 6 (User) and Sections 2, 3, 4, and 5 (Programmer) (although even this isn't entirely true, I've got a "UNIX User's Manual" published in 1986, red ATTIS-style cover, that contains what appear to be selections from Sections 1, 2, and 3...it seems more geared towards folks writing portable software between SVR1 and SVR2 than anything) Finally, here are the omissions I compared with the SVR2 BTL, SVR2 DEC, and 1986 manual mentioned above: Removed by SVR2 public, only in the BTL version: - nscstat(1) - nsctorje(1) - nusend(1) - stlogin(1) - ststat(1) Non-portable DEC stuff: - adb(1) - arcv(1) - kasb(1) - net(1) - vpr(1) - maus(2) - x25alnk(3) - This X.25 stuff never shows back up, probably dropped as of SVR2 BTL (1983) - x25clnk(3) - x25hlnk(3) - x25ipvc(3) Non-portable 3B20S stuff: - cprs(1) - hpio(1) Honeywell/GCOS Interop, gone by SVR2 BTL (1983): - dpd(1) - dpr(1) - fget(1) - fsend(1) - gcat(1) - gcosmail(1) Graphics Subsystem, remains in SVR2 so probably not 3B5 supported as of this printing: - gdev(1) - ged(1) - graphics(1) - gutil(1) - stat(1) - toc(1) So just to review, some matters this manual supports: - The initial 3B5 UNIX release seems closest in character to the initial System V version - Many DEC and 3B20-specific components are omitted - The Honeywell/GCOS interop was on the way out the door and likely never ported - The graphics subsystem was not supported on 3B5 as of this release - Synchronous terminals and NSC networking are taken internal likely by this release, certainly by SVR2 - The 3B5 version supported "DATAKIT" and "3B Computer Network" networks - Included a logdir(1) command used in BTL for getting a user's login directory from /etc/passwd - Included an nkill(1) command to kill a process by its (undefined) name - The boot process included a header object for "driver object files" used with a "self-config boot" process If there are any questions or any pages folks think I should peruse for details, just let me know. Otherwise this'll won't be hitting my detailed analysis for a while, I'm currently in the midst of figuring out a branching scheme in my mandiff repo that'll facilitate tracking the various forks, as I've found many changes between V5 and V6 that are *not* reflected in various ways throughout PWB, Program Generic, CB, and 32V (as an example, go look up where lpr(I) is and isn't available.) - Matt G. P.S. Kudos to the production quality of this manual. It's a small binder, the pages are the same size as the earlier comb-bound manuals. The binder rings themselves are fixed to the back cover and the right side of the rings is flat instead of rounded, so the pages sit very nicely whether opened or closed. This compares with the BTL SVR2 binder where the rings are perfectly round and affixed to the spine instead, so they sit differently depending on whether the binder is on a shelf or open on a desk, with pages risking getting all crumpled up getting bunched up at the edge of the rings. Certainly has nothing to do with software or technical history, but the physical nature of the various publications has also been factoring into my study. Here's a picture of the two covers by the way, since I haven't given any visuals on my work in a while: https://i.imgur.com/hhaaxfA.jpeg

2 years

Re: GNU eqn clarifications and reforms

by G. Branden Robinson

At 2023-06-17T05:19:46+1000, Damian McGuckin wrote: > Getting back to groff, that final/terminating sigma, is it still > pronounced as sigma. > > It certainly has no EQN equivalent name and its groff short symbol > name is > > \(ts > > (terminal sigma) which is not like other greek letters. Just > wondering whether it needs a sentence to mention its abscence from > EQN. There are a few others, but they postdate Ossanna troff. From groff_char(7) in 1.23.0.rc4: ϵ \[+e] u03F5 variant epsilon (lunate) ϑ \[+h] u03D1 variant theta (cursive form) ϖ \[+p] u03D6 variant pi (similar to omega) φ \[+f] u03C6 variant phi (curly shape) ς \[ts] u03C2 terminal lowercase sigma + I know of no reason to make these generally available by default in eqn, though, any more than they already are. You can type their special characters in eqn input and assign spacing and style types to them. (This typing system is a GNU eqn feature, not present in AT&T eqn). In fact I have a coupled pair of reforms in mind for GNU eqn: unfastening the definitions of the lowercase Greek special characters from the typeface used for letters (variables), and then defining the lowercase Greek letter eqn macro names ("alpha", "beta", ...) to explicitly use the "letter" style type. https://savannah.gnu.org/bugs/?64232 https://savannah.gnu.org/bugs/?64231 (For example: define alpha ! type "letter" \(*a ! ) This should result in no change for historical documents (except on terminals, where it will fix a bug), and give us some flexibility for users of modern fonts where Greek letters are properly supported in text fonts (i.e., in four styles). The Graphic Systems C/A/T had uppercase Greek available _only_ upright and lowercase Greek _only_ italic. Modern typesetting systems are not so limited. Regards, Branden

2 years

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