From tuhs at tuhs.org Thu Oct 1 09:46:41 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 30 Sep 2026 23:46:41 +0000 Subject: [TUHS] Research Ninth Edition Manual (V1) Found Message-ID: <5ej-AUDZ3kCnMlAZ7f46AGjul4dun66iL1QUG-bMpMK9RLh-2P4SshTnZutHBTJNGTr0_neUdPNV1HXv1IQglDfZccNcGXpN6sir-Lb0zxg=@protonmail.com> Exciting news, I managed to run down a physical copy of volume one of the Ninth Edition Programmer's Manual. I don't think any version of this is currently preserved, so I'll try and get it on my scan docket once I've got my new RISC-V machine all stable. Unfortunately it is just volume one, although given the relative lack of distribution, I wouldn't be surprised if volume two wasn't physically published, but I can't rule that out entirely. Anywho, it is thicker than the Tenth Edition I've also got sitting here, but I haven't had a chance to thumb through the indices to get a feel for what the delta is. An exciting find nonetheless! In the meantime until I get this scanned, happy to entertain any questions on contents. A question myself: What would the reach of V9 have materially been in the late 80s vs. V8 and V10 around it? The only artifacts from V9 I'm aware of are contained in the archive from the batterpudding collection. It seems V9 is pretty darn obscure in the grand scheme of things, so I find myself curious what the likelihood of something a little closer to virgin BTL tapes popping up actually is vs. trying to get hands on backup tapes or images from running systems being used in BTL between 86-89. - Matt G. From tuhs at tuhs.org Thu Oct 1 09:56:42 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Wed, 30 Sep 2026 19:56:42 -0400 Subject: [TUHS] Research Ninth Edition Manual (V1) Found In-Reply-To: <5ej-AUDZ3kCnMlAZ7f46AGjul4dun66iL1QUG-bMpMK9RLh-2P4SshTnZutHBTJNGTr0_neUdPNV1HXv1IQglDfZccNcGXpN6sir-Lb0zxg=@protonmail.com> References: <5ej-AUDZ3kCnMlAZ7f46AGjul4dun66iL1QUG-bMpMK9RLh-2P4SshTnZutHBTJNGTr0_neUdPNV1HXv1IQglDfZccNcGXpN6sir-Lb0zxg=@protonmail.com> Message-ID: Wonderful. Thank you. Sent from a handheld expect more typos than usual On Wed, Sep 30, 2026 at 7:46 PM segaloco via TUHS wrote: > Exciting news, I managed to run down a physical copy of volume one of > the Ninth Edition Programmer's Manual. I don't think any version of > this is currently preserved, so I'll try and get it on my scan docket > once I've got my new RISC-V machine all stable. Unfortunately it is > just volume one, although given the relative lack of distribution, I > wouldn't be surprised if volume two wasn't physically published, but I > can't rule that out entirely. > > Anywho, it is thicker than the Tenth Edition I've also got sitting here, > but I haven't had a chance to thumb through the indices to get a feel > for what the delta is. An exciting find nonetheless! > > In the meantime until I get this scanned, happy to entertain any > questions on contents. A question myself: > > What would the reach of V9 have materially been in the late 80s vs. V8 > and V10 around it? The only artifacts from V9 I'm aware of are > contained in the archive from the batterpudding collection. It seems V9 > is pretty darn obscure in the grand scheme of things, so I find myself > curious what the likelihood of something a little closer to virgin BTL > tapes popping up actually is vs. trying to get hands on backup tapes or > images from running systems being used in BTL between 86-89. > > - Matt G. > From tuhs at tuhs.org Thu Oct 1 10:39:15 2026 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Thu, 01 Oct 2026 00:39:15 +0000 Subject: [TUHS] Research Ninth Edition Manual (V1) Found In-Reply-To: <5ej-AUDZ3kCnMlAZ7f46AGjul4dun66iL1QUG-bMpMK9RLh-2P4SshTnZutHBTJNGTr0_neUdPNV1HXv1IQglDfZccNcGXpN6sir-Lb0zxg=@protonmail.com> References: <5ej-AUDZ3kCnMlAZ7f46AGjul4dun66iL1QUG-bMpMK9RLh-2P4SshTnZutHBTJNGTr0_neUdPNV1HXv1IQglDfZccNcGXpN6sir-Lb0zxg=@protonmail.com> Message-ID: On Sep 30, 2026, at 17:46, segaloco wrote: > Exciting news, I managed to run down a physical copy of volume one of > the Ninth Edition Programmer's Manual. I don't think any version of > this is currently preserved, so I'll try and get it on my scan docket > once I've got my new RISC-V machine all stable. Hi Matt, Fantastic! This reminds me of a V8 tape that was recently discussed, so I looked for other mentioned distributions. Does anyone know the status of these? V8 is among Steve Bagley's magtape collection from the University of Nottingham. Have they been imaged? Lars Brinkhoff was in contact. https://www.tuhs.org/pipermail/tuhs/2026-April/033484.html Ben Huntsman has a copy of V8 and knows of at least 1-2 copies of V10. This was before V8-V10 were added to the archive in June 2020, so the legal situation was unclear. https://www.tuhs.org/pipermail/tuhs/2013-February/005991.html Thalia From tuhs at tuhs.org Thu Oct 1 12:03:24 2026 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Wed, 30 Sep 2026 22:03:24 -0400 Subject: [TUHS] Research Ninth Edition Manual (V1) Found In-Reply-To: <5ej-AUDZ3kCnMlAZ7f46AGjul4dun66iL1QUG-bMpMK9RLh-2P4SshTnZutHBTJNGTr0_neUdPNV1HXv1IQglDfZccNcGXpN6sir-Lb0zxg=@protonmail.com> References: <5ej-AUDZ3kCnMlAZ7f46AGjul4dun66iL1QUG-bMpMK9RLh-2P4SshTnZutHBTJNGTr0_neUdPNV1HXv1IQglDfZccNcGXpN6sir-Lb0zxg=@protonmail.com> Message-ID: > I don't think any version of [v9] is currently preserved. I have a complete set of all volumes and printed forms of all editions; see https://mcilroy.cs.dartmouth.edu/UnixManuals.jpg. If any other needs copying, I could lend it out for the purpose. > I wouldn't be surprised if volume two wasn't physically published Correct. The only editions with a second volume were v6, v7, anf v10. Doug Editor, v7-v10. On Wed, Sep 30, 2026 at 7:46 PM segaloco via TUHS wrote: > > Exciting news, I managed to run down a physical copy of volume one of > the Ninth Edition Programmer's Manual. I don't think any version of > this is currently preserved, so I'll try and get it on my scan docket > once I've got my new RISC-V machine all stable. Unfortunately it is > just volume one, although given the relative lack of distribution, I > wouldn't be surprised if volume two wasn't physically published, but I > can't rule that out entirely. > > Anywho, it is thicker than the Tenth Edition I've also got sitting here, > but I haven't had a chance to thumb through the indices to get a feel > for what the delta is. An exciting find nonetheless! > > In the meantime until I get this scanned, happy to entertain any > questions on contents. A question myself: > > What would the reach of V9 have materially been in the late 80s vs. V8 > and V10 around it? The only artifacts from V9 I'm aware of are > contained in the archive from the batterpudding collection. It seems V9 > is pretty darn obscure in the grand scheme of things, so I find myself > curious what the likelihood of something a little closer to virgin BTL > tapes popping up actually is vs. trying to get hands on backup tapes or > images from running systems being used in BTL between 86-89. > > - Matt G. From tuhs at tuhs.org Thu Oct 1 12:17:59 2026 From: tuhs at tuhs.org (Brantley Coile via TUHS) Date: Thu, 1 Oct 2026 02:17:59 +0000 Subject: [TUHS] Research Ninth Edition Manual (V1) Found In-Reply-To: References: <5ej-AUDZ3kCnMlAZ7f46AGjul4dun66iL1QUG-bMpMK9RLh-2P4SshTnZutHBTJNGTr0_neUdPNV1HXv1IQglDfZccNcGXpN6sir-Lb0zxg=@protonmail.com> Message-ID: <8A06F071-46CE-46A7-99E1-BB1EBBBC3666@coraid.com> My Ninth Edition looks even more smudgy. My collection started with the Sixth Edition, which is still knocking around here somewhere. 1970-76 was a busy time for you folks. > On Sep 30, 2026, at 10:03 PM, Douglas McIlroy via TUHS wrote: > >> I don't think any version of [v9] is currently preserved. > > I have a complete set of all volumes and printed forms of all > editions; see https://mcilroy.cs.dartmouth.edu/UnixManuals.jpg. If any > other needs copying, I could lend it out for the purpose. > >> I wouldn't be surprised if volume two wasn't physically published > > Correct. The only editions with a second volume were v6, v7, anf v10. > > Doug > Editor, v7-v10. > > On Wed, Sep 30, 2026 at 7:46 PM segaloco via TUHS wrote: >> >> Exciting news, I managed to run down a physical copy of volume one of >> the Ninth Edition Programmer's Manual. I don't think any version of >> this is currently preserved, so I'll try and get it on my scan docket >> once I've got my new RISC-V machine all stable. Unfortunately it is >> just volume one, although given the relative lack of distribution, I >> wouldn't be surprised if volume two wasn't physically published, but I >> can't rule that out entirely. >> >> Anywho, it is thicker than the Tenth Edition I've also got sitting here, >> but I haven't had a chance to thumb through the indices to get a feel >> for what the delta is. An exciting find nonetheless! >> >> In the meantime until I get this scanned, happy to entertain any >> questions on contents. A question myself: >> >> What would the reach of V9 have materially been in the late 80s vs. V8 >> and V10 around it? The only artifacts from V9 I'm aware of are >> contained in the archive from the batterpudding collection. It seems V9 >> is pretty darn obscure in the grand scheme of things, so I find myself >> curious what the likelihood of something a little closer to virgin BTL >> tapes popping up actually is vs. trying to get hands on backup tapes or >> images from running systems being used in BTL between 86-89. >> >> - Matt G. From tuhs at tuhs.org Thu Oct 1 15:58:47 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 01 Oct 2026 05:58:47 +0000 Subject: [TUHS] Research Ninth Edition Manual (V1) Found In-Reply-To: <8A06F071-46CE-46A7-99E1-BB1EBBBC3666@coraid.com> References: <5ej-AUDZ3kCnMlAZ7f46AGjul4dun66iL1QUG-bMpMK9RLh-2P4SshTnZutHBTJNGTr0_neUdPNV1HXv1IQglDfZccNcGXpN6sir-Lb0zxg=@protonmail.com> <8A06F071-46CE-46A7-99E1-BB1EBBBC3666@coraid.com> Message-ID: On Wednesday, September 30th, 2026 at 19:18, Brantley Coile via TUHS wrote: > My Ninth Edition looks even more smudgy. My collection started with the Sixth Edition, which is still knocking around here somewhere. I feel quite fortunate to have come across all the things that I have. The comb-bound Eighth Edition manual is now the only research edition in my particular timeframe of study I haven't landed a copy of. In addition that range, I've managed to land a smattering of other USG, PWB, and CB line stuff, some of which is scanned, some of which I have on the docket. I think one of my favorite things is I can pull just about any of the manuals from my bookshelf and learn something new that is still applicable to this day. This speaks not only to the stability and insight in the system, but also the quality of the documentation. Folks to this day can still learn to use UNIX in the words of ken, dmr, bwk, and so on, at the very least in the genealogy of the current POSIX specification and C standards. If anyone's got bookshelf space, get yourself a hardcopy UNIX manual. V7 is a nice start, although you can often times find System III, System V, and BSD manuals on eBay. Just to disclaim I don't resell anything I get on eBay so I'm not invested in manual sales there aside from my own combing for lost works, but there are often copies of things I see which I already have and think, gee, I know a bunch of folks who might appreciate that. Just be nice and scan anything unpreserved if you don't let me get it :) - Matt G. From tuhs at tuhs.org Thu Oct 1 18:05:13 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Thu, 01 Oct 2026 02:05:13 -0600 Subject: [TUHS] Research Ninth Edition Manual (V1) Found In-Reply-To: References: <5ej-AUDZ3kCnMlAZ7f46AGjul4dun66iL1QUG-bMpMK9RLh-2P4SshTnZutHBTJNGTr0_neUdPNV1HXv1IQglDfZccNcGXpN6sir-Lb0zxg=@protonmail.com> <8A06F071-46CE-46A7-99E1-BB1EBBBC3666@coraid.com> Message-ID: <202610010805.69185DXm031016@freefriends.org> I have a comb-bound 8th Edition manual. BWK got it for me, many years ago. (More like decades, at this point. :-) It's a bit beat up, particularly the covers. It originally belonged to one Rae McLellan, whom I otherwise know nothing about... I also have a 9th Edition manual that I bought from Bell Labs in the early 90s. I remember corresponding with Doug about it, who said he "had to check if we can sell one to you". :-) It cost me $50, IIRC. Matt, how desperate are you to scan the 8th ed manual? Let's discuss privately. Arnold segaloco via TUHS wrote: > On Wednesday, September 30th, 2026 at 19:18, Brantley Coile via TUHS wrote: > > > My Ninth Edition looks even more smudgy. My collection started with the Sixth Edition, which is still knocking around here somewhere. > > I feel quite fortunate to have come across all the things that I have. > The comb-bound Eighth Edition manual is now the only research edition in > my particular timeframe of study I haven't landed a copy of. In > addition that range, I've managed to land a smattering of other USG, > PWB, and CB line stuff, some of which is scanned, some of which I have > on the docket. > > I think one of my favorite things is I can pull just about any of the > manuals from my bookshelf and learn something new that is still > applicable to this day. This speaks not only to the stability and > insight in the system, but also the quality of the documentation. Folks > to this day can still learn to use UNIX in the words of ken, dmr, bwk, > and so on, at the very least in the genealogy of the current POSIX > specification and C standards. > > If anyone's got bookshelf space, get yourself a hardcopy UNIX manual. > V7 is a nice start, although you can often times find System III, > System V, and BSD manuals on eBay. Just to disclaim I don't resell > anything I get on eBay so I'm not invested in manual sales there aside > from my own combing for lost works, but there are often copies of > things I see which I already have and think, gee, I know a bunch of > folks who might appreciate that. Just be nice and scan anything > unpreserved if you don't let me get it :) > > - Matt G. From tuhs at tuhs.org Thu Oct 1 20:19:26 2026 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Thu, 01 Oct 2026 10:19:26 +0000 Subject: [TUHS] Research Ninth Edition Manual (V1) Found In-Reply-To: (Thalia Archibald via TUHS's message of "Thu, 01 Oct 2026 00:39:15 +0000") References: <5ej-AUDZ3kCnMlAZ7f46AGjul4dun66iL1QUG-bMpMK9RLh-2P4SshTnZutHBTJNGTr0_neUdPNV1HXv1IQglDfZccNcGXpN6sir-Lb0zxg=@protonmail.com> Message-ID: <7wmrsxsoy9.fsf@junk.nocrew.org> Thalia Archibald wrote: > This reminds me of a V8 tape that was recently discussed, so I looked > for other mentioned distributions. Does anyone know the status of > these? V8 is among Steve Bagley's magtape collection from the > University of Nottingham. Have they been imaged? Lars Brinkhoff was > in contact. When I asked around about the tapes I didn't sense any urgency in the reponses, so I didn't push Bagley to do something about them. Also I gather QUIC tapes are difficult to process, and I didn't see anyone who was willing to take them on. From tuhs at tuhs.org Fri Oct 2 01:08:29 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 01 Oct 2026 15:08:29 +0000 Subject: [TUHS] Research Ninth Edition Manual (V1) Found In-Reply-To: <202610010805.69185DXm031016@freefriends.org> References: <5ej-AUDZ3kCnMlAZ7f46AGjul4dun66iL1QUG-bMpMK9RLh-2P4SshTnZutHBTJNGTr0_neUdPNV1HXv1IQglDfZccNcGXpN6sir-Lb0zxg=@protonmail.com> <8A06F071-46CE-46A7-99E1-BB1EBBBC3666@coraid.com> <202610010805.69185DXm031016@freefriends.org> Message-ID: On Thursday, October 1st, 2026 at 01:05, arnold at skeeve.com wrote: > Matt, how desperate are you to scan the 8th ed manual? Let's > discuss privately. > > Arnold Thanks for the offer Arnold! That one isn't too high on my priority list only in that we do have the manpage sources in the archive which isn't the case with V9 to my knowledge, I think its the only research edition without a scan or sources available currently. I may pursue hardcopy scans of V8 eventually, but my stack is pretty high right now as it is, so keeping a tight focus on what I take on presently. If it does come up I can let you know, thanks again! - Matt G. From tuhs at tuhs.org Fri Oct 2 08:00:12 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 01 Oct 2026 22:00:12 +0000 Subject: [TUHS] UNIX Reference Card (Was: Vi Quick Reference card for 4.4 BSD) Message-ID: > On Friday, January 9th, 2026 at 00:58, Jonathan Gray via TUHS tuhs at tuhs.org wrote: > > > On Wed, Jan 07, 2026 at 05:24:13PM -0800, Mary Ann Horton via TUHS wrote: > > > > I had some extra time today, so I went ahead and scanned the Cherry card and > > the Bolsky card. > > > > The Cherry card is unique in that the pages aren't all the same length. Each > > section has slightly longer pages, with a "tab" heading at the bottom of the > > first page of each section. See the 3rd page of the PDF for the full effect. > > > > https://stargatemuseum.org/maps/UNIX_Reference_Card_Second_Edition_by_L.L.Cherry.pdf > > > > https://stargatemuseum.org/maps/UNIX_System_Quick_Guide.pdf > > > > Thanks, > > > > /Mary Ann Horton/ (she/her/ma'am) > > Award Winning Author > > maryannhorton.com https://maryannhorton.com > > Thank you. I see Warren has also added these to the archive. > > https://www.tuhs.org/Archive/Documentation/Cards/ Just bumping this old topic to let folks know I finally found an original of the First Edition reference card that I had uploaded a crusty old multi-generation photo-copy of previously. The URL is unchanged: https://www.tuhs.org/Archive/Documentation/Cards/UNIX_Reference_Card_by_L.L.Cherry.pdf The README in the parent directory is also updated with this info. - Matt G. From tuhs at tuhs.org Fri Oct 2 21:52:09 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Fri, 02 Oct 2026 05:52:09 -0600 Subject: [TUHS] Research Ninth Edition Manual (V1) Found In-Reply-To: References: <5ej-AUDZ3kCnMlAZ7f46AGjul4dun66iL1QUG-bMpMK9RLh-2P4SshTnZutHBTJNGTr0_neUdPNV1HXv1IQglDfZccNcGXpN6sir-Lb0zxg=@protonmail.com> Message-ID: <202610021152.692Bq9Sx001571@freefriends.org> Doug, What version / edition is the manual in the lower lefthand corner from? It has the black cover with the number/letter blocks on it. Thanks, Arnold Douglas McIlroy via TUHS wrote: > > I don't think any version of [v9] is currently preserved. > > I have a complete set of all volumes and printed forms of all > editions; see https://mcilroy.cs.dartmouth.edu/UnixManuals.jpg. If any > other needs copying, I could lend it out for the purpose. > > > I wouldn't be surprised if volume two wasn't physically published > > Correct. The only editions with a second volume were v6, v7, anf v10. > > Doug > Editor, v7-v10. > > On Wed, Sep 30, 2026 at 7:46 PM segaloco via TUHS wrote: > > > > Exciting news, I managed to run down a physical copy of volume one of > > the Ninth Edition Programmer's Manual. I don't think any version of > > this is currently preserved, so I'll try and get it on my scan docket > > once I've got my new RISC-V machine all stable. Unfortunately it is > > just volume one, although given the relative lack of distribution, I > > wouldn't be surprised if volume two wasn't physically published, but I > > can't rule that out entirely. > > > > Anywho, it is thicker than the Tenth Edition I've also got sitting here, > > but I haven't had a chance to thumb through the indices to get a feel > > for what the delta is. An exciting find nonetheless! > > > > In the meantime until I get this scanned, happy to entertain any > > questions on contents. A question myself: > > > > What would the reach of V9 have materially been in the late 80s vs. V8 > > and V10 around it? The only artifacts from V9 I'm aware of are > > contained in the archive from the batterpudding collection. It seems V9 > > is pretty darn obscure in the grand scheme of things, so I find myself > > curious what the likelihood of something a little closer to virgin BTL > > tapes popping up actually is vs. trying to get hands on backup tapes or > > images from running systems being used in BTL between 86-89. > > > > - Matt G. From tuhs at tuhs.org Fri Oct 2 22:03:43 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Fri, 02 Oct 2026 06:03:43 -0600 Subject: [TUHS] Research Ninth Edition Manual (V1) Found In-Reply-To: <202610010805.69185DXm031016@freefriends.org> References: <5ej-AUDZ3kCnMlAZ7f46AGjul4dun66iL1QUG-bMpMK9RLh-2P4SshTnZutHBTJNGTr0_neUdPNV1HXv1IQglDfZccNcGXpN6sir-Lb0zxg=@protonmail.com> <8A06F071-46CE-46A7-99E1-BB1EBBBC3666@coraid.com> <202610010805.69185DXm031016@freefriends.org> Message-ID: <202610021203.692C3h6E002451@freefriends.org> Arnold Robbins via TUHS wrote: > I have a comb-bound 8th Edition manual. BWK got it for me, many years > ago. (More like decades, at this point. :-) It's a bit beat up, > particularly the covers. > > It originally belonged to one Rae McLellan, whom I otherwise know > nothing about... I asked Doug and Brian: > From: Douglas McIlroy > Date: Thu, 1 Oct 2026 09:55:43 -0400 > Subject: Re: Who was Rae McLellan? > > Rae McLellan was a go-to hardware designer and builder. If memory > serves, he participated in projects like UCDS (Unx circuit design > system) and TPC (The Phone Company, a novel switch architecture that > ran the department telephones) and chip design. At one point his > health declined inexplicably until he realized that his septic system > was contaminating his well. Rae was one of the old guard that stuck > with the Labs after many CS people decamped around the year 2000. > > Doug Brian adds: > Date: Thu, 1 Oct 2026 10:02:36 -0400 (EDT) > To: Douglas McIlroy > cc: arnold at skeeve.com > Subject: Re: Who was Rae McLellan? > > I have a (ever dimmer) memory that Rae also worked with Dave Ditzel > on the CRISP processors that Dave then carried further when he founded > TransMeta. But treat this with a grain of salt. From tuhs at tuhs.org Fri Oct 2 22:50:18 2026 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Fri, 2 Oct 2026 08:50:18 -0400 Subject: [TUHS] Research Ninth Edition Manual (V1) Found In-Reply-To: <202610021203.692C3h6E002451@freefriends.org> References: <5ej-AUDZ3kCnMlAZ7f46AGjul4dun66iL1QUG-bMpMK9RLh-2P4SshTnZutHBTJNGTr0_neUdPNV1HXv1IQglDfZccNcGXpN6sir-Lb0zxg=@protonmail.com> <8A06F071-46CE-46A7-99E1-BB1EBBBC3666@coraid.com> <202610010805.69185DXm031016@freefriends.org> <202610021203.692C3h6E002451@freefriends.org> Message-ID: > What version / edition is the manual in the lower lefthand corner from? > It has the black cover with the number/letter blocks on it. That's the trade publication of v7, typeset from the same source as the Bell Labs publication. On Fri, Oct 2, 2026 at 8:04 AM Arnold Robbins via TUHS wrote: > > Arnold Robbins via TUHS wrote: > > > I have a comb-bound 8th Edition manual. BWK got it for me, many years > > ago. (More like decades, at this point. :-) It's a bit beat up, > > particularly the covers. > > > > It originally belonged to one Rae McLellan, whom I otherwise know > > nothing about... > > I asked Doug and Brian: > > > From: Douglas McIlroy > > Date: Thu, 1 Oct 2026 09:55:43 -0400 > > Subject: Re: Who was Rae McLellan? > > > > Rae McLellan was a go-to hardware designer and builder. If memory > > serves, he participated in projects like UCDS (Unx circuit design > > system) and TPC (The Phone Company, a novel switch architecture that > > ran the department telephones) and chip design. At one point his > > health declined inexplicably until he realized that his septic system > > was contaminating his well. Rae was one of the old guard that stuck > > with the Labs after many CS people decamped around the year 2000. > > > > Doug > > Brian adds: > > > Date: Thu, 1 Oct 2026 10:02:36 -0400 (EDT) > > To: Douglas McIlroy > > cc: arnold at skeeve.com > > Subject: Re: Who was Rae McLellan? > > > > I have a (ever dimmer) memory that Rae also worked with Dave Ditzel > > on the CRISP processors that Dave then carried further when he founded > > TransMeta. But treat this with a grain of salt. From tuhs at tuhs.org Fri Oct 2 23:16:51 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Fri, 02 Oct 2026 07:16:51 -0600 Subject: [TUHS] Research Ninth Edition Manual (V1) Found In-Reply-To: References: <5ej-AUDZ3kCnMlAZ7f46AGjul4dun66iL1QUG-bMpMK9RLh-2P4SshTnZutHBTJNGTr0_neUdPNV1HXv1IQglDfZccNcGXpN6sir-Lb0zxg=@protonmail.com> <8A06F071-46CE-46A7-99E1-BB1EBBBC3666@coraid.com> <202610010805.69185DXm031016@freefriends.org> <202610021203.692C3h6E002451@freefriends.org> Message-ID: <202610021316.692DGpWi008376@freefriends.org> Douglas McIlroy wrote: > > What version / edition is the manual in the lower lefthand corner from? > > It has the black cover with the number/letter blocks on it. > > That's the trade publication of v7, typeset from the same source as > the Bell Labs publication. Ah. Thanks! Arnold From tuhs at tuhs.org Sun Oct 4 07:30:16 2026 From: tuhs at tuhs.org (William Cheswick via TUHS) Date: Sat, 3 Oct 2026 17:30:16 -0400 Subject: [TUHS] Research Ninth Edition Manual (V1) Found In-Reply-To: <5ej-AUDZ3kCnMlAZ7f46AGjul4dun66iL1QUG-bMpMK9RLh-2P4SshTnZutHBTJNGTr0_neUdPNV1HXv1IQglDfZccNcGXpN6sir-Lb0zxg=@protonmail.com> References: <5ej-AUDZ3kCnMlAZ7f46AGjul4dun66iL1QUG-bMpMK9RLh-2P4SshTnZutHBTJNGTr0_neUdPNV1HXv1IQglDfZccNcGXpN6sir-Lb0zxg=@protonmail.com> Message-ID: I believe I have both volumes in pretty good condition upstairs. I haven’t been following the discussion, but do you need copies to scan? Ches > On Sep 30, 2026, at 19:47, segaloco via TUHS wrote: > > Exciting news, I managed to run down a physical copy of volume one of > the Ninth Edition Programmer's Manual. I don't think any version of > this is currently preserved, so I'll try and get it on my scan docket > once I've got my new RISC-V machine all stable. Unfortunately it is > just volume one, although given the relative lack of distribution, I > wouldn't be surprised if volume two wasn't physically published, but I > can't rule that out entirely. > > Anywho, it is thicker than the Tenth Edition I've also got sitting here, > but I haven't had a chance to thumb through the indices to get a feel > for what the delta is. An exciting find nonetheless! > > In the meantime until I get this scanned, happy to entertain any > questions on contents. A question myself: > > What would the reach of V9 have materially been in the late 80s vs. V8 > and V10 around it? The only artifacts from V9 I'm aware of are > contained in the archive from the batterpudding collection. It seems V9 > is pretty darn obscure in the grand scheme of things, so I find myself > curious what the likelihood of something a little closer to virgin BTL > tapes popping up actually is vs. trying to get hands on backup tapes or > images from running systems being used in BTL between 86-89. > > - Matt G. From tuhs at tuhs.org Mon Oct 5 16:07:56 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 05 Oct 2026 06:07:56 +0000 Subject: [TUHS] Research Ninth Edition Manual (V1) Found In-Reply-To: References: <5ej-AUDZ3kCnMlAZ7f46AGjul4dun66iL1QUG-bMpMK9RLh-2P4SshTnZutHBTJNGTr0_neUdPNV1HXv1IQglDfZccNcGXpN6sir-Lb0zxg=@protonmail.com> Message-ID: On Saturday, October 3rd, 2026 at 14:30, William Cheswick via TUHS wrote: > I believe I have both volumes in pretty good condition upstairs. I haven’t been following the discussion, but do you need copies to scan? > > Ches Hi Ches! I'd happily scan anything you might have in this regard. One question though, Doug mentioned that only Volume 1 of the Eighth and Ninth Editions were published. Are you referring to having Volume 1 of each or do you happen to have some long-lost Volume 2 of either? Whichever is the case, yes, happy to discuss what that looks like and cover the shipping and handling. - Matt G. From tuhs at tuhs.org Fri Oct 9 15:43:19 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Fri, 9 Oct 2026 15:43:19 +1000 Subject: [TUHS] A Followup on Recent Malicious Unsubscriptions Message-ID: All, just a followup. Recently about six TUHS/COFF members e-mailed me to say that thet had received a "confirm your unsubscription from the list" e-mail when they clearly hadn't asked to unsubscribe. For the last person, I was able to dig through the system logs and I saw the unsubscribe request come from vaderetro-safeunsubscribe.com. According to Google: vaderetro-safeunsubscribe.com is a domain used by the Safe Unsubscribe Service by Hornetsecurity (formerly developed by Vade, previously known as Vade Retro).   It automates one-click unsubscriptions from newsletters or commercial emails directly within webmail or email client interfaces, sparing users from hunting down tiny unsubscribe links at the bottom of messages.  The system detects unsubscribe options inside List-Unsubscribe headers or email bodies, then programmatically pings or triggers HTTP/HTTPS/MAILTO requests via its infrastructure to process the opt-out.  I asked the last person and they say that they have never heard of this service and definitely do not use it. I've tried to contact vaderetro-safeunsubscribe.com about the issue and I've had no response from them. That's all I have: some new data about the issue but no resolution. Cheers, Warren From tuhs at tuhs.org Thu Oct 22 15:46:14 2026 From: tuhs at tuhs.org (ron minnich via TUHS) Date: Wed, 21 Oct 2026 22:46:14 -0700 Subject: [TUHS] the first busybox Message-ID: The first busybox I recall using was on Sun systems (SuntTools?) where many window applications were linked into one binary. I may have got the various names wrong; it's been 35 years. But I'm wondering: did something predate that? What was the "first busybox"? Thanks From tuhs at tuhs.org Thu Oct 22 15:53:41 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Wed, 21 Oct 2026 23:53:41 -0600 Subject: [TUHS] the first busybox In-Reply-To: References: Message-ID: On Wed, Oct 21, 2026 at 11:46 PM ron minnich via TUHS wrote: > The first busybox I recall using was on Sun systems (SuntTools?) where many > window applications were linked into one binary. > I believe then that SunView was the name. I seem to recall it did this because there was no shared library support and the toolkit was large relative to the clients that were linked together. > I may have got the various names wrong; it's been 35 years. But I'm > wondering: did something predate that? > > What was the "first busybox"? It was released with SunOs 3.0. However, I see on the SunView wiki that SunWindows preceded it in 1983, but was much more limited. Maybe define busybox a bit better? What are you looking for? There were several old-time unix programs that behaved differently depending on which hard link you ran them with, but that was much more limited than busybox that massages the .o files to give each a namespace and includes a first level dispatch so you can call foo_main(). Warner From tuhs at tuhs.org Fri Oct 23 01:02:44 2026 From: tuhs at tuhs.org (ron minnich via TUHS) Date: Thu, 22 Oct 2026 08:02:44 -0700 Subject: [TUHS] the first busybox In-Reply-To: References: Message-ID: defining busybox is interesting because there have been so many types. There was the SunView approach you mentioned. My memory was that it was all based on linker scripts, hence non-intrusive one source. at LANL, Erik Hendriks created a busybox using linker scripts, to combine 4 daemons into one, primarily for space. So that's the linker approach. It was non-intrusive. The common C busybox asks people to write programs in a special manner, so they can be compiled together. The Rust coreutils takes this approach too. It's intrusive. The u-root busybox uses the go AST package to write standalone commands into one binary, each command becoming a Go package, so that's a non-intrusive source-based approach. I got to wondering how far back this idea went in the Unix world. I just can't remember. On Wed, Oct 21, 2026 at 10:53 PM Warner Losh wrote: > > > On Wed, Oct 21, 2026 at 11:46 PM ron minnich via TUHS > wrote: > >> The first busybox I recall using was on Sun systems (SuntTools?) where >> many >> window applications were linked into one binary. >> > > I believe then that SunView was the name. I seem to recall it did this > because there > was no shared library support and the toolkit was large relative to the > clients that > were linked together. > > >> I may have got the various names wrong; it's been 35 years. But I'm >> wondering: did something predate that? >> >> What was the "first busybox"? > > > It was released with SunOs 3.0. > > However, I see on the SunView wiki that SunWindows preceded it in 1983, > but was much more limited. > > Maybe define busybox a bit better? What are you looking for? There were > several old-time > unix programs that behaved differently depending on which hard link you > ran them with, but > that was much more limited than busybox that massages the .o files to give > each a namespace > and includes a first level dispatch so you can call foo_main(). > > Warner > From tuhs at tuhs.org Fri Oct 23 01:06:43 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Thu, 22 Oct 2026 09:06:43 -0600 Subject: [TUHS] the first busybox In-Reply-To: References: Message-ID: <202610221506.69MF6hJM038804@freefriends.org> ron minnich via TUHS wrote: > I got to wondering how far back this idea went in the Unix world. I just > can't remember. As Warner mentioned, some commands did this based on looking at argv[0]. In particular, System III and IV had cp, ln, and mv all in one binary. That was circa 1980. I'm not sure I know of others. Arnold From tuhs at tuhs.org Fri Oct 23 02:11:51 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Thu, 22 Oct 2026 12:11:51 -0400 Subject: [TUHS] the first busybox In-Reply-To: References: Message-ID: On Thu, Oct 22, 2026 at 1:46 AM ron minnich via TUHS wrote: > The first busybox I recall using was on Sun systems (SuntTools?) where many > window applications were linked into one binary. > > I may have got the various names wrong; it's been 35 years. But I'm > wondering: did something predate that? > > What was the "first busybox"? I remember seeing something like that with "miniroots", that were meant to be written to a swap partition from a standalone loader, and then you'd boot from swap. I think the IBM RT used that to do installation, or possibly very low-level repair of a busted filesystem. I doubt that predates the Sun window system, though: IBM was late getting thus underpowered boat anchors to market, so I'd imagine the technique was pretty well-known by then. - Dan C. From tuhs at tuhs.org Fri Oct 23 02:29:42 2026 From: tuhs at tuhs.org (Brad Spencer via TUHS) Date: Thu, 22 Oct 2026 12:29:42 -0400 Subject: [TUHS] the first busybox In-Reply-To: (message from ron minnich via TUHS on Thu, 22 Oct 2026 08:02:44 -0700) Message-ID: ron minnich via TUHS writes: > defining busybox is interesting because there have been so many types. > > There was the SunView approach you mentioned. My memory was that it was all > based on linker scripts, hence non-intrusive one source. > > at LANL, Erik Hendriks created a busybox using linker scripts, to combine 4 > daemons into one, primarily for space. So that's the linker approach. It > was non-intrusive. > > The common C busybox asks people to write programs in a special manner, so > they can be compiled together. The Rust coreutils takes this approach too. > It's intrusive. > > The u-root busybox uses the go AST package to write standalone commands > into one binary, each command becoming a Go package, so that's a > non-intrusive source-based approach. > > I got to wondering how far back this idea went in the Unix world. I just > can't remember. > > > On Wed, Oct 21, 2026 at 10:53 PM Warner Losh wrote: NetBSD does the "build all of the C files into one" sort of thing for /rescue. Everything there is a single static position independent binary. There are something like 154 commands there currently. There is some infrastructure in the build system that more or less lets any C command be included in /rescue with very little needing to be dealt with in any sort of special manor. That is, nothing specific is needed in the coding standard to make this all work. The argv[0] trick is used to distinguish between the commands. -- Brad Spencer - brad at anduin.eldar.org From tuhs at tuhs.org Fri Oct 23 02:37:07 2026 From: tuhs at tuhs.org (Phil Budne via TUHS) Date: Thu, 22 Oct 2026 12:37:07 -0400 Subject: [TUHS] the first busybox In-Reply-To: References: Message-ID: <202610221637.69MGb730081158@ultimate.com> Warner Losh wrote: > ron minnich wrote: > > The first busybox I recall using was on Sun systems (SuntTools?) where many > > window applications were linked into one binary. > I believe then that SunView was the name. The sunview name came about in SunOS 3. Before that it was suntools. From tuhs at tuhs.org Fri Oct 23 03:24:07 2026 From: tuhs at tuhs.org (Marc Donner via TUHS) Date: Thu, 22 Oct 2026 13:24:07 -0400 Subject: [TUHS] the first busybox In-Reply-To: References: Message-ID: When Ken and Dennis created exec() they established the convention that argv[0] held the name by which the program was called. Early uses of the argv[0] value to adjust behavior was reported with ex and vi as well as compress and uncompress in the 1970s. I bet we have source references for that somewhere. ===== [I write my own messages. Never from AI.] exploringaimatters.com nygeek.net On Thu, Oct 22, 2026 at 12:12 PM Dan Cross via TUHS wrote: > On Thu, Oct 22, 2026 at 1:46 AM ron minnich via TUHS > wrote: > > The first busybox I recall using was on Sun systems (SuntTools?) where > many > > window applications were linked into one binary. > > > > I may have got the various names wrong; it's been 35 years. But I'm > > wondering: did something predate that? > > > > What was the "first busybox"? > > I remember seeing something like that with "miniroots", that were > meant to be written to a swap partition from a standalone loader, and > then you'd boot from swap. I think the IBM RT used that to do > installation, or possibly very low-level repair of a busted > filesystem. I doubt that predates the Sun window system, though: IBM > was late getting thus underpowered boat anchors to market, so I'd > imagine the technique was pretty well-known by then. > > - Dan C. > From tuhs at tuhs.org Fri Oct 23 04:31:37 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Thu, 22 Oct 2026 12:31:37 -0600 Subject: [TUHS] the first busybox In-Reply-To: References: Message-ID: <202610221831.69MIVb04047459@freefriends.org> Marc Donner via TUHS wrote: > When Ken and Dennis created exec() they established the convention that > argv[0] held the name by which the program was called. Early uses of the > argv[0] value to adjust behavior was reported with ex and vi as well as Late 70s & early 80s > compress and uncompress in the 1970s. I bet we have source references for > that somewhere. compress and uncompress were in the 80s. Unix had pack/unpack but I don't know if they were links to each other or not. Arnold From tuhs at tuhs.org Fri Oct 23 05:28:56 2026 From: tuhs at tuhs.org (Diomidis Spinellis via TUHS) Date: Thu, 22 Oct 2026 22:28:56 +0300 Subject: [TUHS] the first busybox In-Reply-To: References: Message-ID: The ex editor appeared in BSD 1, whereas compress appeared in BSD 4.3 [1]. The ex source code looks for 'd' in second or third string position of the command invocation name [2] to change its behavior to edit or nedit [3]. In this mode, ex disables some magic regular expression characters, enables some notifications, and disables the open and visual commands [4]. I couldn't find in the BSD 1 code for invoking ex in visual mode as vi, although vi is documented as a synonym for ex. [1] https://dspinellis.github.io/unix-history-man/man1.html [2] https://github.com/dspinellis/unix-history-repo/blob/BSD-1-Snapshot-Development/ex-1.1/ex.c#L30 [3] https://github.com/dspinellis/unix-history-repo/blob/BSD-1-Snapshot-Development/ex-1.1/READ_ME#L165 [4] https://begriffs.com/pdf/ex-manual.pdf#page=3 Diomidis - https://www.spinellis.gr On 22-Oct-26 20:24, Marc Donner via TUHS wrote: > When Ken and Dennis created exec() they established the convention that > argv[0] held the name by which the program was called. Early uses of the > argv[0] value to adjust behavior was reported with ex and vi as well as > compress and uncompress in the 1970s. I bet we have source references for > that somewhere. > ===== > [I write my own messages. Never from AI.] > exploringaimatters.com > nygeek.net > > > On Thu, Oct 22, 2026 at 12:12 PM Dan Cross via TUHS wrote: > >> On Thu, Oct 22, 2026 at 1:46 AM ron minnich via TUHS >> wrote: >>> The first busybox I recall using was on Sun systems (SuntTools?) where >> many >>> window applications were linked into one binary. >>> >>> I may have got the various names wrong; it's been 35 years. But I'm >>> wondering: did something predate that? >>> >>> What was the "first busybox"? >> >> I remember seeing something like that with "miniroots", that were >> meant to be written to a swap partition from a standalone loader, and >> then you'd boot from swap. I think the IBM RT used that to do >> installation, or possibly very low-level repair of a busted >> filesystem. I doubt that predates the Sun window system, though: IBM >> was late getting thus underpowered boat anchors to market, so I'd >> imagine the technique was pretty well-known by then. >> >> - Dan C. >> From tuhs at tuhs.org Fri Oct 23 05:39:07 2026 From: tuhs at tuhs.org (Marc Donner via TUHS) Date: Thu, 22 Oct 2026 15:39:07 -0400 Subject: [TUHS] the first busybox In-Reply-To: References: Message-ID: Thank you, Diomidis, for finding evidence in the source. I guess Obi-wan was right - "Use the source, Luke." ===== [I write my own messages. Never from AI.] exploringaimatters.com nygeek.net On Thu, Oct 22, 2026 at 3:29 PM Diomidis Spinellis wrote: > The ex editor appeared in BSD 1, whereas compress appeared in BSD 4.3 > [1]. The ex source code looks for 'd' in second or third string > position of the command invocation name [2] to change its behavior to > edit or nedit [3]. In this mode, ex disables some magic regular > expression characters, enables some notifications, and disables the open > and visual commands [4]. I couldn't find in the BSD 1 code for invoking > ex in visual mode as vi, although vi is documented as a synonym for ex. > > [1] https://dspinellis.github.io/unix-history-man/man1.html > [2] > > https://github.com/dspinellis/unix-history-repo/blob/BSD-1-Snapshot-Development/ex-1.1/ex.c#L30 > [3] > > https://github.com/dspinellis/unix-history-repo/blob/BSD-1-Snapshot-Development/ex-1.1/READ_ME#L165 > [4] https://begriffs.com/pdf/ex-manual.pdf#page=3 > > Diomidis - https://www.spinellis.gr > > On 22-Oct-26 20:24, Marc Donner via TUHS wrote: > > When Ken and Dennis created exec() they established the convention that > > argv[0] held the name by which the program was called. Early uses of the > > argv[0] value to adjust behavior was reported with ex and vi as well as > > compress and uncompress in the 1970s. I bet we have source references > for > > that somewhere. > > ===== > > [I write my own messages. Never from AI.] > > exploringaimatters.com > > nygeek.net > > > > > > On Thu, Oct 22, 2026 at 12:12 PM Dan Cross via TUHS > wrote: > > > >> On Thu, Oct 22, 2026 at 1:46 AM ron minnich via TUHS > >> wrote: > >>> The first busybox I recall using was on Sun systems (SuntTools?) where > >> many > >>> window applications were linked into one binary. > >>> > >>> I may have got the various names wrong; it's been 35 years. But I'm > >>> wondering: did something predate that? > >>> > >>> What was the "first busybox"? > >> > >> I remember seeing something like that with "miniroots", that were > >> meant to be written to a swap partition from a standalone loader, and > >> then you'd boot from swap. I think the IBM RT used that to do > >> installation, or possibly very low-level repair of a busted > >> filesystem. I doubt that predates the Sun window system, though: IBM > >> was late getting thus underpowered boat anchors to market, so I'd > >> imagine the technique was pretty well-known by then. > >> > >> - Dan C. > >> > > From tuhs at tuhs.org Fri Oct 23 05:57:59 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Thu, 22 Oct 2026 13:57:59 -0600 Subject: [TUHS] the first busybox In-Reply-To: References: Message-ID: <202610221957.69MJvxFo054698@freefriends.org> Diomidis Spinellis via TUHS wrote: > The ex editor appeared in BSD 1, whereas compress appeared in BSD 4.3 > [1]. Compress was posted in one of the USENET source groups well before 4.3 BSD was released; the BSD guys merely bundled it into the release. Just for whatever it's worth. Arnold From tuhs at tuhs.org Fri Oct 23 07:08:05 2026 From: tuhs at tuhs.org (Mary Ann Horton via TUHS) Date: Thu, 22 Oct 2026 14:08:05 -0700 Subject: [TUHS] the first busybox In-Reply-To: References: Message-ID: In 3BSD, ex, edit, vi, and vedit were links to the same binary. ex.c looks for 'v ' (start in visual mode) or 'd' (safe edit) anywhere in argv[0], or 'a' in the first character. ('a' was a check for 'a.out' for debugging, later removed.) Bill Joy would have added the checks for 'v' and 'a', probably in 77 or 78. I added the 'd' for 'edit' or 'vedit' in 78, arranging that novice users could invoke it that way to help protect them from common mistakes (like confusion about whether you were in input or command mode). Later I added a check for 'w' so 'view' would invoke the editor in readonly mode. The 'd' was a follow-on from my version of ed ('hed', Horton's Editor) at U Wisconsin in 77. A hard link 'shed' started it as Safe Hed, with protections turned on. I believe it was common practice back then to check argv[0] to allow a program to behave differently depending on the name it was called by. I certainly wasn't the first. On 10/22/26 12:28, Diomidis Spinellis via TUHS wrote: > The ex editor appeared in BSD 1, whereas compress appeared in BSD 4.3 > [1].  The ex source code looks for 'd' in second or third string > position of the command invocation name [2] to change its behavior to > edit or nedit [3].  In this mode, ex disables some magic regular > expression characters, enables some notifications, and disables the > open and visual commands [4].  I couldn't find in the BSD 1 code for > invoking ex in visual mode as vi, although vi is documented as a > synonym for ex. Thanks, /Mary Ann Horton/ (she/her/ma'am)       Keynote Speaker on Inclusion and Innovation       Award Winning Author maryannhorton.com From tuhs at tuhs.org Fri Oct 23 07:17:45 2026 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Thu, 22 Oct 2026 17:17:45 -0400 Subject: [TUHS] the first busybox In-Reply-To: References: Message-ID: <5d05d878-a248-4497-b9d6-cda4fa080460@case.edu> On 10/22/26 5:08 PM, Mary Ann Horton via TUHS wrote: > I believe it was common practice back then to check argv[0] to allow a > program to behave differently depending on the name it was called by. I > certainly wasn't the first. sh/rsh, for instance. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From tuhs at tuhs.org Fri Oct 23 07:21:43 2026 From: tuhs at tuhs.org (Steffen Nurpmeso via TUHS) Date: Thu, 22 Oct 2026 23:21:43 +0200 Subject: [TUHS] the first busybox In-Reply-To: References: Message-ID: <20261022212143.M_rSl3Ca@steffen%sdaoden.eu> Mary Ann Horton via TUHS wrote in : |In 3BSD, ex, edit, vi, and vedit were links to the same binary. ex.c |looks for 'v ' (start in visual mode) or 'd' (safe edit) anywhere in |argv[0], or 'a' in the first character. ('a' was a check for 'a.out' for |debugging, later removed.) Bill Joy would have added the checks for 'v' |and 'a', probably in 77 or 78. I added the 'd' for 'edit' or 'vedit' in |78, arranging that novice users could invoke it that way to help protect |them from common mistakes (like confusion about whether you were in |input or command mode). Later I added a check for 'w' so 'view' would |invoke the editor in readonly mode. | |The 'd' was a follow-on from my version of ed ('hed', Horton's Editor) |at U Wisconsin in 77. A hard link 'shed' started it as Safe Hed, with |protections turned on. | |I believe it was common practice back then to check argv[0] to allow a |program to behave differently depending on the name it was called by. I |certainly wasn't the first. And today "they" ("we") are about to add some getexecpath() into standards, and certain BSDs have week long runs to remove argv[0] in favour of that function in all programs (at least daemons) of the base system. (Not to distress anyone again because of my shock not to ever have though about that argv can be NULL.) --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 tuhs at tuhs.org Fri Oct 23 07:31:34 2026 From: tuhs at tuhs.org (Mychaela Falconia via TUHS) Date: Thu, 22 Oct 2026 13:31:34 -0800 Subject: [TUHS] the first busybox In-Reply-To: References: Message-ID: <20261022213136.8FD697C1915@kcmo.usa2g.org> Mary Ann Horton wrote: > I added the 'd' for 'edit' or 'vedit' in > 78, arranging that novice users could invoke it that way to help protect > them from common mistakes (like confusion about whether you were in > input or command mode). What is 'vedit' mode? At least in the version that made it into 4.3BSD, 'edit' turns on 'noopen' mode that disables 'open' and 'visual' - so what does it mean to have a "novice" mode that is also visual? M~ From tuhs at tuhs.org Fri Oct 23 07:48:54 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 22 Oct 2026 21:48:54 +0000 Subject: [TUHS] the first busybox In-Reply-To: <20261022212143.M_rSl3Ca@steffen%sdaoden.eu> References: <20261022212143.M_rSl3Ca@steffen%sdaoden.eu> Message-ID: On Thursday, October 22nd, 2026 at 14:23, Steffen Nurpmeso via TUHS wrote: > And today "they" ("we") are about to add some getexecpath() into > standards, and certain BSDs have week long runs to remove argv[0] > in favour of that function in all programs (at least daemons) of > the base system. (Not to distress anyone again because of my > shock not to ever have though about that argv can be NULL.) > > --steffen Interesting, had a double take at this one. Took a look at ANSI and indeed it looks like this can happen. ANSI C says argc must be non-negative, but can be zero apparently. Only if it is non-zero then is argv[0] guaranteed to be a pointer to a string representation of the name of the invoked program. Was this made flexible for environments in hosted environments in which there is no way (or desire) to pass this information to main()? I could see this being the case for freestanding environments, but an extension like POSIX I imagine wouldn't be layered on top of a freestanding environment anyway. That said, I looked further and interestingly the April 1986 Trial Use copy of POSIX 1003.1 in section 3.1.2.2 gives the main(argc, argv) signature with a note: > where argc is the argument count (one or greater), argv is an array > of character pointers to the arguments themselves... whereas the final from 1989 gives: > where argc is the argument count and argv is an array of character > pointers to the arguments themselves. So the "one or greater" note is dropped. Either way, both then go on to say: > The value in argv[0] should point to a filename that is associated > with the process being started by one of the exec functions. So is this to imply along the way to POSIX they acknowledged that ANSI C does not guarantee argc > 0 and argv != NULL and decided to align? - Matt G. From tuhs at tuhs.org Fri Oct 23 08:04:12 2026 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Thu, 22 Oct 2026 15:04:12 -0700 Subject: [TUHS] the first busybox In-Reply-To: References: Message-ID: <88D32432-6E2E-4B64-AC36-C08CB7F8BC24@iitbombay.org> From James Da Silva's Crunch-0.2 README (1994): The linking together of different programs by hand is an old space-saving technique. Crunch automates the process by building the necessary stub files and makefile for you (via the crunchgen program), and by doctoring the symbol tables of the component .o files to allow them to link without "symbol multiply defined" conflicts (via the crunchide program). I think Poul-Henning had something similar before then. This was the difference from earlier programs such as vi/ex/view that behaved differently based on argv[0]. Totally non-intrusive! I think even the Go technique is somewhat intrusive. > On Oct 22, 2026, at 8:02 AM, ron minnich via TUHS wrote: > > defining busybox is interesting because there have been so many types. > > There was the SunView approach you mentioned. My memory was that it was all > based on linker scripts, hence non-intrusive one source. > > at LANL, Erik Hendriks created a busybox using linker scripts, to combine 4 > daemons into one, primarily for space. So that's the linker approach. It > was non-intrusive. > > The common C busybox asks people to write programs in a special manner, so > they can be compiled together. The Rust coreutils takes this approach too. > It's intrusive. > > The u-root busybox uses the go AST package to write standalone commands > into one binary, each command becoming a Go package, so that's a > non-intrusive source-based approach. > > I got to wondering how far back this idea went in the Unix world. I just > can't remember. > > > On Wed, Oct 21, 2026 at 10:53 PM Warner Losh wrote: > >> >> >> On Wed, Oct 21, 2026 at 11:46 PM ron minnich via TUHS >> wrote: >> >>> The first busybox I recall using was on Sun systems (SuntTools?) where >>> many >>> window applications were linked into one binary. >>> >> >> I believe then that SunView was the name. I seem to recall it did this >> because there >> was no shared library support and the toolkit was large relative to the >> clients that >> were linked together. >> >> >>> I may have got the various names wrong; it's been 35 years. But I'm >>> wondering: did something predate that? >>> >>> What was the "first busybox"? >> >> >> It was released with SunOs 3.0. >> >> However, I see on the SunView wiki that SunWindows preceded it in 1983, >> but was much more limited. >> >> Maybe define busybox a bit better? What are you looking for? There were >> several old-time >> unix programs that behaved differently depending on which hard link you >> ran them with, but >> that was much more limited than busybox that massages the .o files to give >> each a namespace >> and includes a first level dispatch so you can call foo_main(). >> >> Warner >> From tuhs at tuhs.org Fri Oct 23 08:13:11 2026 From: tuhs at tuhs.org (Steffen Nurpmeso via TUHS) Date: Fri, 23 Oct 2026 00:13:11 +0200 Subject: [TUHS] the first busybox In-Reply-To: References: <20261022212143.M_rSl3Ca@steffen%sdaoden.eu> Message-ID: <20261022221311._VreveDp@steffen%sdaoden.eu> segaloco via TUHS wrote in : |On Thursday, October 22nd, 2026 at 14:23, Steffen Nurpmeso via TUHS \ | wrote: |> And today "they" ("we") are about to add some getexecpath() into |> standards, and certain BSDs have week long runs to remove argv[0] |> in favour of that function in all programs (at least daemons) of |> the base system. (Not to distress anyone again because of my |> shock not to ever have though about that argv can be NULL.) | |Interesting, had a double take at this one. Took a look at ANSI and Too much honour. I think we were once there in the past already. K&R says in "5.10 Command-line Arguments" By convention, argv[0] is the name by which the program was invoked, so argc is at least 1. But in 2021 there was CVE-2021-4034 --- through execve(2) one could enforce another condition, and that caused quite some trouble. Now, if i ask Google AI it says Abstract: OS Handling of argc == 0 (Post-PwnKit) The PwnKit vulnerability (CVE-2021-4034) exposed a critical security flaw rooted in how operating system kernels handle processes executed with an empty argument vector (argc == 0). When a binary is executed via execve() with no arguments, a memory overlap can occur between the argument array (argv) and the environment array (envp), allowing local attackers to inject malicious environment variables into high-privilege SUID-root binaries. Operating systems addressed this architectural risk differently: Linux Kernel: Historically permitted argc == 0. To prevent application-level crashes while eliminating the vulnerability, the Linux kernel was patched to proactively inject an empty string ("") as the first argument whenever a process attempts to execute with an empty argv. This forces argc to become 1 in user space, safely neutralizing the out-of-bounds memory read. OpenBSD: Was inherently immune to this vector because its kernel strictly enforces POSIX compliance at the system call level. OpenBSD’s execve() implementation rejects empty argument vectors outright and returns an error if at least one non-null argument is not present. FreeBSD: While traditionally less vulnerable due to a more restrictive memory mapping behavior and the absence of pkexec as a default SUID binary, FreeBSD developers audited and hardened the kernel's argument validation routines (kern_exec.c) to ensure robust checking of argument pointers during process creation. |indeed it looks like this can happen. ANSI C says argc must be |non-negative, but can be zero apparently. Only if it is non-zero then |is argv[0] guaranteed to be a pointer to a string representation of the |name of the invoked program. Was this made flexible for environments in |hosted environments in which there is no way (or desire) to pass this |information to main()? I could see this being the case for freestanding |environments, but an extension like POSIX I imagine wouldn't be layered |on top of a freestanding environment anyway. | |That said, I looked further and interestingly the April 1986 Trial Use |copy of POSIX 1003.1 in section 3.1.2.2 gives the main(argc, argv) |signature with a note: | |> where argc is the argument count (one or greater), argv is an array |> of character pointers to the arguments themselves... | |whereas the final from 1989 gives: | |> where argc is the argument count and argv is an array of character |> pointers to the arguments themselves. | |So the "one or greater" note is dropped. Either way, both then go on to |say: | |> The value in argv[0] should point to a filename that is associated |> with the process being started by one of the exec functions. | |So is this to imply along the way to POSIX they acknowledged that ANSI C |does not guarantee argc > 0 and argv != NULL and decided to align? I would never overestimate it, you surely read too much in that only. --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 tuhs at tuhs.org Fri Oct 23 08:26:13 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 22 Oct 2026 22:26:13 +0000 Subject: [TUHS] Exec With 0 and NULL argc and argv? (was: the first busybox) Message-ID: <_OVPprIF6oUXZ0dk1mMcrVQLAN8SXMlQYn9EtWUyce5sAkcyHzqTZOGE2Jy-rADX1_wsWaSRarQZg083aIdZHJ_kUDGMRv7HXIxV38e_-lw=@protonmail.com> On Thursday, October 22nd, 2026 at 15:13, Steffen Nurpmeso via TUHS wrote: > Too much honour. I think we were once there in the past already. > K&R says in "5.10 Command-line Arguments" > > By convention, argv[0] is the name by which the program was > invoked, so argc is at least 1. > > But in 2021 there was CVE-2021-4034 --- through execve(2) one > could enforce another condition, and that caused quite some > trouble. Now, if i ask Google AI it says > > [insert AI digest here detailing kernel/execs supporting argc == 0] > > ... > > --steffen Ah that all makes a bit more sense...so it's more about various kernels allowing a process to be exec'd without compliant argc/argv passing rather than legitimate situations where it's completely reasonable to expect these to be 0/NULL it seems. That's what I get from your AI digest anyway. So at the end of the day the problem being solved is the fact that, despite standards committees' best efforts, many kernels and exec mechanisms seem to let you get into this messy state? I'm just surprised that the solution is yet another call rather than kernels just getting cleaned up to prevent this. Is there some legitimate reason to exec something and zero out the argument info? Is the new function added as to not break applications that *do* depend on argc == 0 despite it being recognized as generally bad all around in a hosted environment? - Matt G. From tuhs at tuhs.org Fri Oct 23 08:56:53 2026 From: tuhs at tuhs.org (Steffen Nurpmeso via TUHS) Date: Fri, 23 Oct 2026 00:56:53 +0200 Subject: [TUHS] Exec With 0 and NULL argc and argv? (was: the first busybox) In-Reply-To: <_OVPprIF6oUXZ0dk1mMcrVQLAN8SXMlQYn9EtWUyce5sAkcyHzqTZOGE2Jy-rADX1_wsWaSRarQZg083aIdZHJ_kUDGMRv7HXIxV38e_-lw=@protonmail.com> References: <_OVPprIF6oUXZ0dk1mMcrVQLAN8SXMlQYn9EtWUyce5sAkcyHzqTZOGE2Jy-rADX1_wsWaSRarQZg083aIdZHJ_kUDGMRv7HXIxV38e_-lw=@protonmail.com> Message-ID: <20261022225653.mW8rBrya@steffen%sdaoden.eu> segaloco via TUHS wrote in <_OVPprIF6oUXZ0dk1mMcrVQLAN8SXMlQYn9EtWUyce5sAkcyHzqTZOGE2Jy-rADX1_wsWaS\ RarQZg083aIdZHJ_kUDGMRv7HXIxV38e_-lw=@protonmail.com>: |On Thursday, October 22nd, 2026 at 15:13, Steffen Nurpmeso via TUHS \ | wrote: | |> Too much honour. I think we were once there in the past already. |> K&R says in "5.10 Command-line Arguments" |> |> By convention, argv[0] is the name by which the program was |> invoked, so argc is at least 1. |> |> But in 2021 there was CVE-2021-4034 --- through execve(2) one |> could enforce another condition, and that caused quite some |> trouble. Now, if i ask Google AI it says |> |> [insert AI digest here detailing kernel/execs supporting argc == 0] |> ... |Ah that all makes a bit more sense...so it's more about various kernels |allowing a process to be exec'd without compliant argc/argv passing |rather than legitimate situations where it's completely reasonable to |expect these to be 0/NULL it seems. That's what I get from your AI |digest anyway. Yes, but there was quite a turmoil and many programs were hastily patched. |So at the end of the day the problem being solved is the fact that, |despite standards committees' best efforts, many kernels and exec |mechanisms seem to let you get into this messy state? I'm just |surprised that the solution is yet another call rather than kernels just |getting cleaned up to prevent this. Is there some legitimate reason to |exec something and zero out the argument info? Is the new function |added as to not break applications that *do* depend on argc == 0 despite |it being recognized as generally bad all around in a hosted environment? The reason is "quite another", best i quote the issue [1] There is currently no standardized, portable mechanism in POSIX to retrieve the absolute pathname of the executable file currently executing the calling process. Runtimes, language interpreters, and asset loaders must resort to highly unportable, platform-specific mechanisms. - Linux relies on parsing the "/proc/self/exe" symlink or using `getauxval(AT_EXECFN)`. - FreeBSD and NetBSD use a sysctl interface via KERN_PROC_PATHNAME. - SunOS implements getexecname(). - macOS implements a non-POSIX _NSGetExecutablePath() function. Others like OpenBSD force us to rely on argv[0] and (if the process didn't start with an absolute path) scanning the PATH environment variable, which is fundamentally unsafe and unreliable (someone else in the PATH with the same name appearing early is picked up). Furthermore, the parent process can easily manipulate or empty argv and envp during an execve() call, leaving the child completely unable to safely determine its own physical location. Adding a native, safe API to POSIX eliminates immense cross-platform boilerplate across programming frameworks and toolchains that require explicit binary path auditing. However there is chroot(2) and namespaces with mount overlays, or even entire abstractions like CloudABI[2] was. As in, "what is a pathname worth". It was suggested to instead use something like getauxval(2) (Linux) AT_EXECFD, the file descriptor of the program. Maybe getauxval(3) as such would be the best, there are several items that really make sense for many. Yet then OpenBSD went ahead and implemented that plain thing, and mostly got rid of argv[0] in the base system (at least many, many changes were done by de Raadt), in favour of that thing, doing kind of basename(3) as necessary first. [1] https://www.austingroupbugs.net/view.php?id=1992 [2] https://lwn.net/Articles/674770/ --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 tuhs at tuhs.org Fri Oct 23 09:09:13 2026 From: tuhs at tuhs.org (Mary Ann Horton via TUHS) Date: Thu, 22 Oct 2026 16:09:13 -0700 Subject: [TUHS] the first busybox In-Reply-To: <20261022213136.8FD697C1915@kcmo.usa2g.org> References: <20261022213136.8FD697C1915@kcmo.usa2g.org> Message-ID: <6aeb11a2-b2ab-429f-905a-93d08df4e9a9@mhorton.net> That's interesting. My recollection must be fuzzy. I see vedit in SVR4 vi (it turns on "novice", "showmode", "report=1", and turns off "magic", and doesn't touch "open") but not 4BSD. I must have added it after going to Bell Labs in 1981. vi was added to USG UNIX 4.2 in 1983, IIRC. I thought I sent ex/vi updates back to Berkeley until 1983. Apparently not. Thanks, /Mary Ann Horton/ (she/her/ma'am)       Keynote Speaker on Inclusion and Innovation       Award Winning Author maryannhorton.com On 10/22/26 14:31, Mychaela Falconia wrote: > Mary Ann Horton wrote: > >> I added the 'd' for 'edit' or 'vedit' in >> 78, arranging that novice users could invoke it that way to help protect >> them from common mistakes (like confusion about whether you were in >> input or command mode). > What is 'vedit' mode? At least in the version that made it into > 4.3BSD, 'edit' turns on 'noopen' mode that disables 'open' and > 'visual' - so what does it mean to have a "novice" mode that is also > visual? > > M~ From tuhs at tuhs.org Fri Oct 23 11:17:07 2026 From: tuhs at tuhs.org (Charles Anthony via TUHS) Date: Thu, 22 Oct 2026 18:17:07 -0700 Subject: [TUHS] the first busybox In-Reply-To: <6aeb11a2-b2ab-429f-905a-93d08df4e9a9@mhorton.net> References: <20261022213136.8FD697C1915@kcmo.usa2g.org> <6aeb11a2-b2ab-429f-905a-93d08df4e9a9@mhorton.net> Message-ID: Busybox in the sense of an executable doing different things depending on the command used dates back to Multics. In Multics, a segment could have "alias" names assigned to it; similar to soft links but part of the segment metadata rather than a directory entry. An executable segment includes a symbol table listing defined entry points, and the binder (linker) would add alias names to the segment corresponding to those entry points. When one of the alias names was used as a shell command, execution would be started at that entry point. Thus writing something like the tiny Linux busyboxes that combined several shell commands into a single executable was straightforward -- write a binder command file that pulled in all of the compiled command segments and whatever support routines needed and list the wanted entry points. Invoke the binder and it creates a segment with all of the code and aliases to the entry points. -- Charles On Thu, Oct 22, 2026 at 4:09 PM Mary Ann Horton via TUHS wrote: > That's interesting. My recollection must be fuzzy. > > I see vedit in SVR4 vi (it turns on "novice", "showmode", "report=1", > and turns off "magic", and doesn't touch "open") but not 4BSD. I must > have added it after going to Bell Labs in 1981. vi was added to USG UNIX > 4.2 in 1983, IIRC. > > I thought I sent ex/vi updates back to Berkeley until 1983. Apparently not. > > Thanks, > > /Mary Ann Horton/ (she/her/ma'am) > Keynote Speaker on Inclusion and Innovation > Award Winning Author > maryannhorton.com > > > > On 10/22/26 14:31, Mychaela Falconia wrote: > > Mary Ann Horton wrote: > > > >> I added the 'd' for 'edit' or 'vedit' in > >> 78, arranging that novice users could invoke it that way to help protect > >> them from common mistakes (like confusion about whether you were in > >> input or command mode). > > What is 'vedit' mode? At least in the version that made it into > > 4.3BSD, 'edit' turns on 'noopen' mode that disables 'open' and > > 'visual' - so what does it mean to have a "novice" mode that is also > > visual? > > > > M~ -- X-Clacks-Overhead: GNU Terry Pratchett From tuhs at tuhs.org Fri Oct 23 16:02:52 2026 From: tuhs at tuhs.org (Greg 'groggy' Lehey via TUHS) Date: Fri, 23 Oct 2026 17:02:52 +1100 Subject: [TUHS] the first busybox In-Reply-To: <202610221506.69MF6hJM038804@freefriends.org> References: <202610221506.69MF6hJM038804@freefriends.org> Message-ID: On Thursday, 22 October 2026 at 9:06:43 -0600, Arnold Robbins via TUHS wrote: > ron minnich via TUHS wrote: > >> I got to wondering how far back this idea went in the Unix world. I just >> can't remember. > > As Warner mentioned, some commands did this based on looking at > argv[0]. In particular, System III and IV had cp, ln, and mv all in > one binary. That was circa 1980. I'm not sure I know of others. They're still there. FreeBSD still has a number of linked executables in /bin: [ and test, ed and red, csh and tcsh, pgrep and pkill, link and ln, rm and unlink. Some look just like different names, and I don't know to what extent their behaviour depends on the name, but pgrep and pkill have different functionality. Then in /sbin there are 24 different names for sha1 and friends and 17 different names for geom and similar. The man page for sha1 suggests that the behaviour does depend on the name. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From tuhs at tuhs.org Fri Oct 23 16:18:07 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Fri, 23 Oct 2026 00:18:07 -0600 Subject: [TUHS] the first busybox In-Reply-To: References: <202610221506.69MF6hJM038804@freefriends.org> Message-ID: On Fri, Oct 23, 2026, 12:02 AM Greg 'groggy' Lehey wrote: > On Thursday, 22 October 2026 at 9:06:43 -0600, Arnold Robbins via TUHS > wrote: > > ron minnich via TUHS wrote: > > > >> I got to wondering how far back this idea went in the Unix world. I just > >> can't remember. > > > > As Warner mentioned, some commands did this based on looking at > > argv[0]. In particular, System III and IV had cp, ln, and mv all in > > one binary. That was circa 1980. I'm not sure I know of others. > > They're still there. FreeBSD still has a number of linked executables > in /bin: [ and test, ed and red, csh and tcsh, pgrep and pkill, link > and ln, rm and unlink. Some look just like different names, and I > don't know to what extent their behaviour depends on the name, but > pgrep and pkill have different functionality. Then in /sbin there are > 24 different names for sha1 and friends and 17 different names for > geom and similar. The man page for sha1 suggests that the behaviour > does depend on the name. > Not to mention /rescue, which has been around about as long as NetBSD has had it since both are based on crunchgen. NetBSD had it in 2002 and FreeBSD in 2003, so rather late in the game. Warner Greg > -- > Sent from my desktop computer. > Finger grog at lemis.com for PGP public key. > See complete headers for address and phone numbers. > This message is digitally signed. If your Microsoft mail program > reports problems, please read http://lemis.com/broken-MUA.php > From tuhs at tuhs.org Sat Oct 24 02:43:43 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Fri, 23 Oct 2026 10:43:43 -0600 Subject: [TUHS] the first busybox In-Reply-To: References: <202610221506.69MF6hJM038804@freefriends.org> Message-ID: On Fri, Oct 23, 2026 at 12:18 AM Warner Losh wrote: > > > On Fri, Oct 23, 2026, 12:02 AM Greg 'groggy' Lehey wrote: > >> On Thursday, 22 October 2026 at 9:06:43 -0600, Arnold Robbins via TUHS >> wrote: >> > ron minnich via TUHS wrote: >> > >> >> I got to wondering how far back this idea went in the Unix world. I >> just >> >> can't remember. >> > >> > As Warner mentioned, some commands did this based on looking at >> > argv[0]. In particular, System III and IV had cp, ln, and mv all in >> > one binary. That was circa 1980. I'm not sure I know of others. >> >> They're still there. FreeBSD still has a number of linked executables >> in /bin: [ and test, ed and red, csh and tcsh, pgrep and pkill, link >> and ln, rm and unlink. Some look just like different names, and I >> don't know to what extent their behaviour depends on the name, but >> pgrep and pkill have different functionality. Then in /sbin there are >> 24 different names for sha1 and friends and 17 different names for >> geom and similar. The man page for sha1 suggests that the behaviour >> does depend on the name. >> > > Not to mention /rescue, which has been around about as long as NetBSD has > had it since both are based on crunchgen. NetBSD had it in 2002 and FreeBSD > in 2003, so rather late in the game. > I've been reminded that FreeBSD 2.0's installer did a similar thing with a hacky shell script in 1994 so it could fit on a floppy. crunchgen replaced that. Warner