TUHS

tuhs@tuhs.org

28 participants
6556 discussions

Apple Darwin 0.1 and 0.3 sort of running on x86!

by Jason Stevens

I don't know if this is of any interest to anyone here, but 1999 is 18 years ago, so maybe it counts as old? Over on nextcomputers.org various users had found a backup of next68k.org which included a wget of the old source http://nextftp.onionmixer.net/next.68k.org/otto/html/pub/Darwin/PublicSource /Darwin/index.html So I found a copy of Rhapsody DR-2, the last binary version of this Mach 2.5+4.4BSD and after a day got a kernel to build. Another day and I had it interfacing to the driverkit to load drivers. After a post on reddit someone gave me a link to some kdx p2p network, where they had a Darwin 0.3 toast image. using what I learned with Darwin 0.1 I got the 0.3 to build as well. I uploaded a bunch of stuff here: https://sourceforge.net/projects/aapl-darwin/ although it seems to not let me upload the toast images themselves. I did slam together a minimal Darwin 0.3 qemu image that can sort-of boot to single user mode. It's not even slightly useful, but it does show that it works. https://sourceforge.net/projects/aapl-darwin/files/qemu-images/Darwin03_qemu 090_24_4_2017.7z/download

8 years, 3 months

Re: [TUHS] There is turmoil in Linux-land - When did rm first avoid going upwards?

by jnc＠mercury.lcs.mit.edu

> From: Kurt H Maier > /etc/glob, which appears to report no-match if the first character is . So I couldn't be bothered to work out how 'glob' worked exactly, so I just did an experiment: I created a hacked version of 'rm' that had the directory handling call to glob call 'echo' instead of 'rm'; it also printed 'tried' instead of the actual unlink call, and printed 'cd' when it changed directories. I then set up two subsidiary directors, foo and .bar, with one containing '.foo0 foo1' and the other '.bar0 bar1'. Saying 'xrm -r -f .*' produced this: cd: . -r -f foo xrm xrm.c cd: .. -r -f foo xrm xrm.c cd: .bar -r -f bar1 (This system has /tmp on a mounted file system, which is why the 'cd ..' was a NOP. And a very good thing, too; at one point the phone rang, and it distracted me, and I automatically typed 'rm', not 'xrm'... see below for what happened. No biggie, there were only my test files there. The output lines are "-r -f foo xrm xrm.c" because that's what 'glob' passed to 'echo'.) Saying 'xrm -r -f *' produced this: cd: foo -r -f foo1 xrm: tried xrm.c: tried So apparently 'glob', when presented with '*' , ignores entries starting with '.', but '.*' does not. When I stupidly typed 'rm -r -f .*', it did more or les what I originally thought it would: deleted all the files in all the directories (but only on the /tmp device, because .. linked to the itself in /tmp, so it didn't escape from that volume); leaving all the directories, but empty, except for the files .foo0 and .bar0. So files and inferior directories with names starting with '.' would have escaped, but nothing else. Noel

8 years, 3 months

Re: [TUHS] There is turmoil in Linux-land - When did rm first avoid going upwards?

by jnc＠mercury.lcs.mit.edu

> From: "Ron Natalie" > Actually, it's the shell that calls glob. Yes, in the initial expansion of the command line, but V6 'rm' also uses 'glob' internally; if the '-r' flag is given, and the current name in the command argument list is a directory, viz.: if ((buf->mode & 060000) == 040000) { if (rflg) { ... execl("/etc/glob", "glob", "rm", "-r", fflg? "-f": "*", fflg? "*": p, 0); printf("%s: no glob\n", arg); exit(); } (where 'p' is 0 - no idea why the writer didn't just say '"*": 0, 0'). So "rm -f foo*", where the current directory contains file 'foo0 foo1 foo2' and directoty 'foobar', and directory 'foobar' contains 'bar0 bar1 bar2', the first instance of 'glob' (run by the shell) expands the 'foo0 foo1 foo2 foobar' and the second instance (run by 'rm') expands the 'bar0 bar1 bar2'. > Glob then invokes the command (in this case rm). I don't totally grok 'glob', but it is prepared to exec() either the command name, /bin/{command} or /usr/bin/{command}; but if that file is not executable it tries feeding it to the shell, on the assumption it must be a shell command list: execv(file, arg); if (errno==ENOEXEC) { arg[0] = file; *--arg = "/bin/sh"; execv(*arg, arg); } I guess (too lazy to look) that the execv() must return a different error number if the file doesn't exist at all, so it only tries the shell if the file existed, but wasn't executable. Noel

8 years, 3 months

Runaway rm -r

by Ron Natalie

There was an incident at Pixar that a runaway rm ate most of the Toy Story 2 movie. The only thing that saved them was an employee had their own copy on a machine at home. We never lost the whole disk through one of these, but we did have a guy wipe out /etc/passwd one day. Our password fields had an rfc-822ish user name in the gcos field, so it looked something like: ron::51:50:Ronald Natalie <ron>:/sys1/ron: Well, one of our users decided to grep for a user (alas while root) with the command grep <howard> /etc/passwd

8 years, 3 months

There is turmoil in Linux-land - When did rm first avoid going upwards?

by Josh Good

Hello all. It's off-topic for this list, but there is turmoil in Linux-land. A bug was discovered in systemd, whereby systemd re-implemented "rm" functionality without following POSIX "rm" behaviour. This could kill a system, as explained here: https://github.com/systemd/systemd/issues/5644 The reference POSIX "rm" behaviour is that "rm -rf .*" should NOT delete the current and parent directories, as stated here: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm.html#tag_20_11… So, to get on-topic, I have a question for UNIX historians: when was it first defined in the UNIX realm that "rm -r .*" should NOT delete the current and parent directories? Would the command "cd /tmp ; rm -rf .*" be able to kill a V6 or V7 UNIX system? Regards, -- Josh Good

8 years, 3 months

Zilog Z80 Unix

by Erik E. Fair

I have a memory of having seen a Zilog Z-80 (not Z8002 like the Onyx) based Unix, possibly v6, at a vendor show or conference - perhaps the West Coast Computer Faire (WCCF) in the late 1970s or early 1980s. I recall asking the people in the booth how they managed without an MMU, and don't recall their answer. I do remember thinking that since Unix had "grown up" with MMUs to stomp on obvious pointer mistakes, the software ought to be relatively well-behaved ... you know: not trying to play "core war" with itself? I searched the TUHS archives cursorily with Google to see if this has been previously mentioned, but pretty much all Z80 CPU references have for its use in "smart" I/O devices back in the day. Does anyone else remember this Z80 Unix and who did it? Or maybe that it was a clone of some kind ... ? looking for a little history, Erik Fair

8 years, 3 months

Bourne shell and comments

by Warren Toomey

I was trying to configure C news on 2.9BSD today and I found that its Bourne shell doesn't grok # comments. The Bourne shell in 2.11BSD does. So I thought: when did the Bourne (and other) shells first grok # as indicating a comment? Was this in response to #! being added to the kernel, or was it the other way around? And was the choice of #! arbitrary, or was it borrowed from somewhere else? Datum point: 2.9BSD's kernel can recognise #!, but the sh can't recognise #. Cheers, Warren

8 years, 4 months

Re: [TUHS] Bourne shell and comments

by Doug McIlroy

"Shebang". Nice coinage (which I somehow hadn't heard before). Very much in tune with Bell Labs, where Vic Vyssotsky had instilled "sharp" as the name of # -- not "number", not "pound", and definitely not "hash" -- so shell scripts began with sharp-bang. Doug

8 years, 4 months

Tektronix 8560 floppies

by Christian Groessler

Hi, I've imaged (with ImageDisk) some floppies I've got with my "new" 8560 system. You can find them at ftp://ftp.groessler.org/pub/chris/tektronix/8560/diskimages . Among other things there are cross-assemblers for 68000, 6809, and 6800. From the TNIX installation disk set one is missing (disk 5 of 5). I'm looking for the Z8000 cross-assembler for TNIX. Does anyone have it? regards, chris

8 years, 4 months

Etymology of shebang

by Ron Natalie

Oldest actual use in a post I can find is 1997 I did find something I had completely forgot about. The csh used to (probably still does?) differentiate between Bourne shell scripts and csh scripts by looking for #.

8 years, 4 months

Re: [TUHS] Zilog Z80 Unix

by jnc＠mercury.lcs.mit.edu

> From: "Erik E. Fair" > I have a memory of having seen a Zilog Z-80 .... based Unix, possibly v6 > ... I recall asking the people in the booth how they managed without an > MMU, and don't recall their answer. I do remember thinking that since > Unix had "grown up" with MMUs to stomp on obvious pointer mistakes, the > software ought to be relatively well-behaved I don't know about the Z80 part, but for the MMU aspect, recall that the first couple of versions of PDP-11 Unix ran on a model (the -11/20) which didn't have an MMU (although, as mentioned before here, it apparently did later use a thing called a KS11, the specifications for which seem to be mostly lost). Although recall the mention of calling out "a.out!", as to the hazards of doing so... And of course there was the 'Unix for an LSI-11' (LSX), although I gather that was somewhat lobotomized, as the OS and application has to fit into 56KB total. So it was possible to 'sorta kind-of' do Unix without an MMU. Noel

8 years, 4 months

Re: [TUHS] Bourne shell and comments

by Doug McIlroy

> Is this a reason why "#" was chosen as the root prompt, by the way? No. # was adopted as superuser prompt before the shell had a comment convention. Doug

8 years, 4 months

make inn automatically accept new group control messages

by John Floren

Looks like INN isn't quite as trusting as CNews, so it doesn't automatically create a group when it receives a control message. Anyone know how to make it do that, or at least email me to notify of the new group? john

8 years, 4 months

SunOS 4 documentation

by Cory Smelosky

All, Does anyone have SunOS 4 documentation? I am trying to properly configure UUCP and I am unable to find proper documentation. -- Cory Smelosky b4(a)gewt.net

8 years, 4 months

Re: [TUHS] TeX/troff/typesetting markups - Re: SunOS 4 documentation

by Doug McIlroy

>From M.Douglas.McIlroy(a)dartmouth.edu Mon Apr 17 10:43:01 2017 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.cs.dartmouth.edu X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,RCVD_IN_SORBS_SPAM,SPF_HELO_PASS autolearn=no autolearn_force=no version=3.4.1 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01lp0181.outbound.protection.outlook.com [216.32.181.181]) by mail.cs.Dartmouth.EDU (8.15.2/8.15.2) with ESMTPS id v3HEh0wA031412 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK) for <doug(a)cs.dartmouth.edu>; Mon, 17 Apr 2017 10:43:00 -0400 Resent-Date: Mon, 17 Apr 2017 10:43:00 -0400 Resent-Message-Id: <201704171443.v3HEh0wA031412(a)mail.cs.Dartmouth.EDU> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dartmouth.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4n+i0BYc99O1LsJUlq/3+Fe7LWU50mdGY+GqJ4s6gE4=; b=DMhdEDi8FZGl0vh183BK4hRB0JlC9zz1vFrtXGj2Xu+zC14yq2nErQ6GklgyH/McZ14nEEr3pd6GCt/XwC8IPiJHpb6ezLmsbHqNixcefKg0zgKWqNwZ2UI/bo+SGD6nBF2iWvJ2mPNwEYatCD38aJnIhhSIstPwBFMseWGzzY0= Resent-From: <M.Douglas.McIlroy(a)dartmouth.edu> Received: from BN6PR03CA0091.namprd03.prod.outlook.com (10.164.122.157) by DM5PR03MB2761.namprd03.prod.outlook.com (10.168.198.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Mon, 17 Apr 2017 14:42:56 +0000 Received: from BY2FFO11FD033.protection.gbl (2a01:111:f400:7c0c::199) by BN6PR03CA0091.outlook.office365.com (2603:10b6:405:6f::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10 via Frontend Transport; Mon, 17 Apr 2017 14:42:56 +0000 Authentication-Results: spf=pass (sender IP is 209.85.213.43) smtp.mailfrom=gmail.com; dartmouth.edu; dkim=pass (signature was verified) header.d=gmail.com;dartmouth.edu; dmarc=pass action=none header.from=gmail.com; Received-SPF: Pass (protection.outlook.com: domain of gmail.com designates 209.85.213.43 as permitted sender) receiver=protection.outlook.com; client-ip=209.85.213.43; helo=mail-vk0-f43.google.com; Received: from mail-vk0-f43.google.com (209.85.213.43) by BY2FFO11FD033.mail.protection.outlook.com (10.1.14.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1019.14 via Frontend Transport; Mon, 17 Apr 2017 14:42:55 +0000 Received: by mail-vk0-f43.google.com with SMTP id n73so16676432vke.1 for <M.Douglas.McIlroy(a)dartmouth.edu>; Mon, 17 Apr 2017 07:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=4n+i0BYc99O1LsJUlq/3+Fe7LWU50mdGY+GqJ4s6gE4=; b=FYyXrTL0N56YECium8aaGcHxeArd7+4M0CcK8rV/t84BfWu/kBACFrqKOUWtxH6WQN OsRTLjEcRCrJjNiO4jJriKHJJkdq12hwXXMSYYoooCb03Serd3dambVmTmVagAyVFN/W sgWqIQTNE4VRSTlsMs+9rd3cCkBdboMwePNZOYUs0C+O/ZL+Fj4W07B8tbJKKYCit+Y2 MoQpnpt79ncTmnVusb59PayARQizGLK2ned1BiPGiNFuCWHvNWZBqP17uLZSdMCdJXLv NQs/6Ht0gd8f50ssH06Wu7IU7FZJhocAFl35a9KGLjlL/9H74upFWybii6r7qYDmOiJG Fkyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=4n+i0BYc99O1LsJUlq/3+Fe7LWU50mdGY+GqJ4s6gE4=; b=jBOwl2StXxH4FDuHqiQsoUYRum/TjG/xhsdKrzYLGUWV/3Ydc2dhK2HWubVeOQvJG3 +rjbpGtLNBEtrAfbGSpy1+vpTek9lqwKP/K+gYlME1wbXAaaHHLiW2O0R7Hb9QVJ8HmG oupdoMUnbICeFo37zdjbFxLFL9bk2ca4yNs/k8spElc4M2Y1ttAggjlXDXoUNgc378Ps 1xVJwXpHExY7abcimj8ZxyjJZ5RlRZ8upGC0sXhhkshO143bHE29IaurXZmoHN8JsvNd iRTj70MdXrCzS2KBdJR/O9K3k5VJGZVqs0ar8cyL26cBSo8JGcoW+w48lEP26pJc3LNx EsoA== X-Gm-Message-State: AN3rC/4bSJNvC0yEJ++sTJonVdycbsnEyE5wc/AsLdtTFx0FNPC8pxq4 49Qu9Mw/gf+OzpNO2E3JBTNpqmugaw== X-Received: by 10.31.7.14 with SMTP id 14mr8644558vkh.132.1492440174480; Mon, 17 Apr 2017 07:42:54 -0700 (PDT) MIME-Version: 1.0 Sender: bigroryg(a)gmail.com Received: by 10.176.92.46 with HTTP; Mon, 17 Apr 2017 07:42:34 -0700 (PDT) In-Reply-To: <MWHPR03MB27650B0F0110942E146E552CAD050(a)MWHPR03MB2765.namprd03.prod.outlook.com> References: <MWHPR03MB27650B0F0110942E146E552CAD050(a)MWHPR03MB2765.namprd03.prod.outlook.com> From: Rory Gawler <rgawler(a)gmail.com> Date: Mon, 17 Apr 2017 10:42:34 -0400 X-Google-Sender-Auth: DMbKB3AZJKP7IXygQ6qYGNTVH4k Message-ID: <CAF-wkQ1NTp8Ch_CqCHoOKsTpx4_pdc8pc+TkcssDK+e=L9e_Ug(a)mail.gmail.com> Subject: Re: Indian Ridge To: "M. Douglas McIlroy" <M.Douglas.McIlroy(a)dartmouth.edu> Cc: "trailsbill(a)gmail.com" <trailsbill(a)gmail.com>, "doug(a)cs.dartmouth.edu" <doug(a)cs.dartmouth.edu> Content-Type: multipart/alternative; boundary="001a1143d7a672d411054d5dceaa" X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 995b0936-48d6-40e5-a31e-bf689ec9446f:0 X-Forefront-Antispam-Report: CIP:209.85.213.43;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(8196002)(2980300002)(438002)(199003)(189002)(2171002)(53546009)(98316002)(110136004)(82202002)(7116003)(55446002)(106466001)(356003)(5660300001)(3480700004)(6246003)(42186005)(87572001)(93516999)(61266001)(4326008)(59536001)(50986999)(221733001)(54356999)(76176999)(305945005)(83322999)(8676002)(16003)(7596002)(1096003)(73972006)(73392002)(236005)(6392003)(7636002)(76482006)(84326002)(9896002)(6916009)(189998001)(7846003)(2950100002)(956001)(54906002);DIR:INB;SFP:;SCL:1;SRVR:DM5PR03MB2761;H:mail-vk0-f43.google.com;FPR:;SPF:Pass;MLV:sfv;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BY2FFO11FD033;1:aUgSGmASM+up/A1T0NTlHs3f/ljhfjFjTfxKd66WpgAd+4Ok71jt1PrxNk/prUooNjmvXSGblDccFX6pNr6vCkQZFOj5fSZv2kIVtobBdB9NyEtkr2L9n8hVg5gPJIY+PbNymVbd+Svxhro0bTAMCTdiHCp+VpLlJMhUbBDmONzZUk4B1iVj5SDh757u+e26UrLJGPj4xMFuHTCukKvzAMA7lKsQB/LOWIcjCwQM04N7rHDMZDru+EiVYirKwZ2EzQKnlJuBR1G9BGsPbNew08U9LUfs+e8hsegBr78njkiTij1thYeSvZTGe+/yZIOWTIC4wWFLIv3sYanVjmbrpD1AsnlYDbWxnRd+7iKagaN5DJZBcRqjPwa0mN9PwOfUk1I6aLID5vbJRvih3i8CCyJa++a0EDhjbMquAJ2CY/HE9q68BhNf66xayvwS+xqpiYYVPLc4Kz9MOcZSQs79Gv8yiXHmpi1drdxlXr7bmwxxeCuQ1K473+nCZyx6iN73BYfdnpiTRa0h+l1Wc7TrYgYEENgtigRSnY9/uVtEBgOTqTz/uS+8jjYs+fu2F/7tDyHqFZassAV9K8UGsm04/HjtuBDyMLxDLGIq2o+fgmD+O3UXF++K6J8IcJH+Dpo8j6dEWtC68CjJEFxywo4bYA== X-MS-Office365-Filtering-Correlation-Id: 9409f223-7b61-4a8e-5c11-08d485a008db X-DkimResult-Test: Passed X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(81800236)(8251501002)(3001016)(3010002)(71702078);SRVR:DM5PR03MB2761; X-Microsoft-Exchange-Diagnostics: 1;DM5PR03MB2761;3:v2wlUFM8zxmK6Tj/CNGWkGAahZw8E8kklsdwj4pSYZSWsbQ+ua8F9a88hf2fyGbKRZTvHxHozJrQkhGJs81/SXmsQmj3XYVRns/Q3ciXOxQFLzwRAG5/7kGBrFnocFNDgDoq960Vc4kN3VH7VoCoqCljLaNWAtKADDqlyfMTxTgp2TbcTiLRMvmTQQKPVId0xEru3cQ3H5EOVnRg+BiATNNqb2w8n2hirSzCbOwM3FJR3ig0BPnpYGfCGOrf+bw3TPM9vUrRsxbIjQ6skgBI8zIq4W3uX9Ihuom5lnYdYot6066sBihzyGF2AHCETqcLy/101dlrwagkcakpppKgkvW2du8q1Ll6f118Bk89eSBjeu0Jkd5gL0mZpQNKpKFdbEEp0wO14ptjszHCOYJxDxYo0ZSOiIt5Z6R2L9AiEgvxtRZbm8AQnkBOC4tEN+mvgiVIBHPIQQI81KGaNRoj326hJz2rpiSHgmiSxPFMfD0= X-Microsoft-Exchange-Diagnostics: 1;DM5PR03MB2761;25:tpVJ7VrLshcTggjSpYMoAudpwyvfFwFbEUltyIX2OGI/wmm9Fw5TTnK5qXi3AmaGmEYCXRBU5yMWciSHOesKA5tv3swmL0Othemww86bU8/hhHtqhVYJMbwzeUKw9S6n/fRx50eG3p2kD+a6PnXIATUzTdgk4ISM6uDNtTjJmbK5bHaztBvL5ge+wu2j1x4dKXYvxhJCA6jBESWq3+1OvuG0vNiwedKHxSMLQ8uJofSn9yKppzK7gzn+CHMOKOYAr3HDc3/Lsruh7pfROtM7be89kZr1CwwFBekPuezwPgyYFV3zjlrSNu0NAIs1I9oyTYjClMzGN8jIAJpmwdLeXp0aVC0DIIxNta/NRNb6Y2ZTHvOoviV16XnV8K11COCmrUpENpRlsfmDM8i/lZUcUQaVVhEuch7zQWyZiGL4Q4xIydLNmy8n+UoJasoVzYTwTO935Qn7DqbkCwGpdlCyVg==;31:E1S7SDJ3pY3roIb5uZS3ABMFxbq+0Oj0z4fL1JfLkqAZ6KhXftLxL5qCO1pIrYFoLAIIabqM6REYNfY1A782zjDopiVOzZZBSax6EM0HTls1W5dE/psFJS/tPQA/iQN28DcUun1mgnF3QY7yxan/VMJl6tBNc8419a9yFhA3Z2311HHmQd4gSbYH/FThKah3ss936OIlUrwQXFsR4C7boxsqpxHY2FqDrPgGwlFSgCasXiM9nh/JKAe3Fj4JqzjgSwHWPpIJH7eTmf7clJdJySCF4w7Zl6mZiRY1EP8fxFUXHrwVA8Cpj1QOSJ2BeQPL6dNTortiAhrrjTd5MNXHPw== X-Microsoft-Exchange-Diagnostics: 1;DM5PR03MB2761;20:EFJPXJwWCb7APxjszxZB+54sL0bczY6kOwPeGSV+1iPNTzrAytEhA9zRsoZcwjljRXFJJBg41Edusaa5WXjqVLeduU9g8Vb6TDDTTrlUEiD3nFqECivNrbZLoZuUwdp0uk/mM8wqTgHBTj7i5GcGMDSkTjx+qoGIy8u0KlygnHuUelpCl17VN8stN40XwOhuLXG/qOQfK1XLZZ/JtBYqSWeXiJaCQP0Xzuhg5JjqqgPvWytot+clwc7p9Ik6QlQMDEXb2x1gx1XTnsSrDpS5Xd0HsOTxwnbKPw7gxrBIjJVwY+xtLBxSnTKLGOHquCcihj13uvrr2kTxVGdRj3imLxDeMApi3EX4BVzP+lOm91icgByTpkA7SqFBM8y4klk6Ifd2Guy1vUGZqii9R5BDjQmOYAdy4DE5uiBremOIFzoLt6cH/pdkAVKP3gaOGaAJrU+6DUzCh/ercJaIGCrb1CxqazMqv6fX2O4KAI1caZ19GWKY7GvmPph2FAyGkDKX X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(13023025)(13024025)(13018025)(13016025)(8121501046)(9101536074)(93006095)(93005095)(3002001)(10201501046);SRVR:DM5PR03MB2761;BCL:0;PCL:0;RULEID:;SRVR:DM5PR03MB2761; X-Microsoft-Exchange-Diagnostics: 1;DM5PR03MB2761;4:na1PgqJ0tpiE5q000iAyjM0WxQVQsV8KycOYXJPblbncH1WD1TcjHT8Zw93PShN9wAauArgEPCrSVJqW7d6gZdyPTWxtJI2hB109WEkgCucy/nj5Pr6hi5G5+q3y+851YnIbIPb2U2uyWrnuEkazfyXG+WkyqL/x4+E7GQlveWxWFQrWEXWTPpXqYKuXGVqM88f3375c6oNioYIunLThm1KcnW/w7w0Nn8SHsOF/6KsWTCi0RKwvzCcbgHQEauj99rgUPKXBT1TMTp5BvkE8zAOazwKCp5i9w2pFPqewwV/DESQhsKRTZ77crY1upsuTyOWUZC27vDBJGzuo4BFNu8TX/K73UtGmyOznvdFHM5zqkkul6KqaiQriQ7FzSPTEJ2YPH3oyNSf8bqdcw3dwzKSNxRBikbPT9krP2Hv9P/8StgtRHRuiFi2oo4pYc0C83sU/kQfpIKoxyFrytE5mf85UMKitTFKRS+mjbu4XciA2UxqBTRccfzPLl3OD26BQ X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;DM5PR03MB2761;23:LwuISP4y+h8NukX4EBZQL9NltYyu4fu9xPdz3RVeI?= =?us-ascii?Q?i9z6sgK3AYAwFGziyKKDVpWMCR4AwEo54jaKEzxc9gvY2+EjXAgfXSiFkB2s?= =?us-ascii?Q?TIdz07q8qS0AhyBuH4rFCpaLBexf/4e87GkFNlPi2TgRik0aNU6x6uK3Nd51?= =?us-ascii?Q?Nb2u8GwQHik7EKiO1dgjWccV1EHH5/uqZ1z8ZiZiu2+eAERDpS+oHAY7OIKX?= =?us-ascii?Q?Oya5xa/3biO6jRfleRoVErQwYAkTpqlR4qwxhnCnquvzCkFP6kzkSUuHv+oQ?= =?us-ascii?Q?EAUNJxh8O5jEoxk7YpqiwibfWPlpSh9aGfcEIoXa8oQyH5c6ZKTn1PucLOpl?= =?us-ascii?Q?nTSWy1ipaL8k92nVUJj+XuMcACZ0pziBz+8U+UaaM38D73Hd8CAd0TmwpuUR?= =?us-ascii?Q?Mb1MQB891HSHtoraaS3ksfw5gY7aP9XmK0g2RUa1tK7VAM2HbkUZEu5MAHgg?= =?us-ascii?Q?AxrmXYYfczTTMZV1X/PlurFgU0kz3ouDZjrelzH2EpVYe1/gApHFmX01syU5?= =?us-ascii?Q?JlCaOlPhR0gwB7Er0wJZrJ9vokUw/nOJsVDnSbpPPwUzhqGGkqWqXBnAl4/x?= =?us-ascii?Q?iXTHNezvb7vrmcZReej4lOL0ADKWrA3jIQAk2I0znoK/EBfXiotCMHdGOKs3?= =?us-ascii?Q?h9W/nADQNUdGJkr8YTUMrRlBmdB5r/4d9UIxhyOw5oOeqgfysZYJG2Zca0PD?= =?us-ascii?Q?Ksq98WsRe95TGUbFvxKeucK+fxKk0Y9EuuePIHImpdAevif0RZg2ffBCizVn?= =?us-ascii?Q?iQ7ZF20S+6lNh2nTZIkkbIHu962yF+PT2Kf6FAlqJFADKQ11xC0NClqnz/+k?= =?us-ascii?Q?FMWbx5gR0C6/hO2LWLCr1wiHnYaOPQVrjiiHvQZbVAVk4F1bSnDMYSBeZMMR?= =?us-ascii?Q?AHnLJaMNLGYdLJnlv+VOkmJJAvwvSZAuqnjIMwtpFAhLtkFVzHMasRioCazp?= =?us-ascii?Q?zD7wvYLdSaPa6EP2gLoaUFhggxOkBWpqY1vOvS15qd+4FuwO5nqxd/rtJdg5?= =?us-ascii?Q?nrRO4XxQ+r0v4AGIqYeGEyEqRCJEgBak12uzsyeIBJn0OuuQ71X6wh8US5Sp?= =?us-ascii?Q?Ij1nktNhe6iNwwgGBsjdIJrlYFPrFN5/Itoha0WEwhLnpbvQg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;DM5PR03MB2761;6:SX+ugIsCZ//tDyF0NKcgWSZYh99MZ2poV/mHF/RfXeqPnK1NfCKPCEzvwDOc5QO3pWoGqnaeSZCUhXsbQMjgtM0kZbWutv74sNXdCYbxSes81RTHiPW2qPYIaAD6Nx2KBTpXm/j+bB9YwvJtP1rGbbEmRC6grGINauqnUGzlyJFFXjbgHew2VqjNMTe0IkQ2lZemCDzmJ2IJRzEa+2ksuyay993c75Qun7tyzrxCm6Z4MdvG/BhGG/nAx12tbmqy8xrKriiW/V81dS+5YSq2fmDWuYugvXmjTMsx6uZOLghfdxvDhusbE2iMZwCvhgy30IPYO/ZMEkEiu5C1VbGauJ+MWaHz/INwK6eM+FdkzbmIwzXqo9kpQCVt0A/x6Qp8OCN/Ud7TxOQH2Xk9cmUptZOXdkb9eDARkbuLzL2kHvWrLNZprYtauNLkfkkFk77L;5:X99pImDjLUnqQiBWX30Pg0bbmBOa0GaC27aqlYNiTAMzfRh8R49PIt7ABRaTirneg2R9MlsetzTlue3Ako1aK0lcCYCyQu5SmmBDXYPs7PcYuXWS4K9MGNN3RT9LjskVynrOccGNJs2Tme5cYgaClQ==;24:06s0RlYYWCLALfPGeRPKwtvKIMJb57tc6eSqggLi3oiOiFyawkJt88wQ1VVldEaXkWlblsG3sPJ0qrseupFnro6P4ieZR1KUTb/I+ilFnn4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;DM5PR03MB2761;7:6EchJJQ7hB88FkeDdY59Btwp8XSA6vzo7/U/zdeKa2LOlqjhYTDPvefsF8tENYR6fXqYfGQmFG3mBhiA15ktVFutdIGp0GIYTx/YB7D+lFNl11O/0hggB5Y4qLj7TmcplbzKiHsaSjc4MyqMGMF/JAwZ0KB7SiTtFNdVmZEkzHHotal9uNzDbvB1Zks1bax5SmAGq+T6q3G3t/YP3A0XXAHuLbTJs8+O2cP7/2Gog4Z6Ueca1CZdSLa0KRG3AlpzyiH8b4x6I0eJ+D2ZUFxwhH0McBwkBLPI5JrhrsXYl9bnnVvuROlXey+tl9e67Nc+3av57kJ7n91ctJfQjOn6CDbJXeTJMAnVkMSWSw67LXUUpSmqBtW9XNXGLE11uh84ivyJNJVvxFu7WXLcGg4Ddw== X-MS-Exchange-Inbox-Rules-Loop: M.Douglas.McIlroy(a)dartmouth.edu X-Microsoft-Exchange-Diagnostics: 1;DM5PR03MB2761;20:NCNUDGcUA2CZcPMhlym+ZEJHgEXbBBYdzdEeh9nOe30wfKVGKU071HfnnudgymTpvbkLlP4cRKfwzr+kdvU3Igw1L/ryHROQLZK1DFoXqKE+wqQ1ErbtgeVq0TtMOHWzqx8Z6TpYnzJgmOU67RbwaXVrPXtUZc7HxvTd7qpGVdoLMtS1YEfd9O8QXH1HNVK8ulWxEFboGfBfQlpPQzs9ORv9NVTnYZmp1NEdbGwt1Xqo7BZc3AY14pgk5rzEyhP0QfFpeBMo16LPc9u7bykXzgU9KCM9AyDmV+pSlXzgxWQ+SVU0PtpUThWCDEDy3FQ1Bjc7sFS+RmAARzCQXLTyk/6v5dIOsqy2aHiIq0hdQVmU1iNuK3IXf2lKJwKKVEfqcfpDRjjVDUX9jZXs4Y2UHbglCGHpzb6Por+WloCYQCu+oqMbZfMqpAHaegLSoh2hWype1qHRPlSWUsRRIRZqh0SE7UpZaoU0VPe1Dc73csv8Mp1qlqoXnw4A2q+FsiQjDyqXpX1TA34tooGBtaU0wcDNpBIG0Kx5L68WYCSqd7GDZSSy6M65OHiW+PJ3sJ5+VDKguppSUKKIE4No3Qk7sz/cRxsmPV4AUVzwsweFLQE=;23:GqZ/zFtEitUvsd68daINl4rzH89zLSZ56+awbx+l6cb8sFrb/e0mS/Zz4evWvd0mVY4C7zMZY8Fb+HsDv5bsgri7KDzDPB3IKXnJoAgt2s2sLnZl8FciQik1b0WLVoRtSp1frmpM47vBL6C4C9Wk6A== X-ExternalRecipientOutboundConnectors: 995b0936-48d6-40e5-a31e-bf689ec9446f X-OriginatorOrg: dartmouth.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Apr 2017 14:42:55.5625 (UTC) X-MS-Exchange-CrossTenant-Id: 995b0936-48d6-40e5-a31e-bf689ec9446f X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR03MB2761 Status: R X-Status: A --001a1143d7a672d411054d5dceaa Content-Type: text/plain; charset=UTF-8 Fabulous. Tim McNamara said we should make sure with Vicki Smith that it's not in the conservation easement area and if so, if that's okay? On 14 April 2017 at 17:37, M. Douglas McIlroy < M.Douglas.McIlroy(a)dartmouth.edu> wrote: > Rory, > > A possible tree-felling apportunity exists at the lookout just > north of the summit. The former view toward Baker Tower has > been totally obscured by new growth. If Dartmouth is amenable, > the taller trees might be felled in that patch. There may be > a dozen trees something like 10" in diaameter. > > I saw three other trees at scattered intervals along the > trail, which could be removed, though none is a pressing > hazard: a dead pine >18" and two leaners ~8". > --001a1143d7a672d411054d5dceaa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra">Fabulous.=C2=A0</div><div class= =3D"gmail_extra"><br></div><div class=3D"gmail_extra">Tim McNamara said we = should make sure with Vicki Smith that it's not in the conservation eas= ement area and if so, if that's okay?=C2=A0</div><div class=3D"gmail_ex= tra"><br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ext= ra"><br><div class=3D"gmail_quote">On 14 April 2017 at 17:37, M. Douglas Mc= Ilroy <span dir=3D"ltr"><<a href=3D"mailto:M.Douglas.McIlroy@dartmouth.e= du" target=3D"_blank">M.Douglas.McIlroy(a)dartmouth.edu</a>></span> wrote:= <br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef= t:1px #ccc solid;padding-left:1ex"><div id=3D":1mg" class=3D"a3s aXjCH m15b= 6e663c119796f">Rory,<br> <br> A possible tree-felling apportunity exists at the lookout just<br> north of the summit. The former view toward Baker Tower has<br> been totally obscured by new growth. If Dartmouth is amenable,<br> the taller trees might be felled in that patch. There may be<br> a dozen trees something like 10" in diaameter.<br> <br> I saw three other trees at scattered intervals along the<br> trail, which could be removed, though none is a pressing<br> hazard: a dead pine >18" and two leaners ~8".</div></blockquot= e></div><br><br></div></div> --001a1143d7a672d411054d5dceaa--

8 years, 4 months

Re: [TUHS] TUHS Digest, Vol 17, Issue 41

by David

Just finished it. He isn’t the greatest presenter, and it is an interesting overview of how the Bourne shell got written, including some of the quirks it has to this day. David > On Apr 15, 2017, at 7:00 PM, tuhs-request(a)minnie.tuhs.org wrote: > > Subject: [TUHS] Steven Bourne - early days of unix talk > Message-ID: <201704151756.v3FHuUI4019407(a)freefriends.org> > Content-Type: text/plain; charset=us-ascii > >> From the 9fans list: > > https://www.youtube.com/watch?v=2kEJoWfobpA

8 years, 4 months

FTP issue

by Arrigo Triulzi

May I recommend you use the ftp-proxy setup on OpenBSD? It is well-documented here: https://www.openbsd.org/faq/pf/ftp.html So far it has solved all passive FTP issues behind NAT for me. Arrigo

8 years, 4 months

Re: [TUHS] TeX/troff/typesetting markups - Re: SunOS 4 documentation

by Michael Kerpan

Comparing documents produced by Heirloom troff and modern versions of LaTeX, I just can't see a huge difference. The main thing TeX has going for it is LyX, which makes composing documents a whole lot more comfortable for folks raised on WYSIWYG. If a tool like that was available for troff... Mike On Apr 14, 2017 6:24 PM, "Toby Thain" <toby(a)telegraphics.com.au> wrote: On 2017-04-14 9:56 AM, Michael Kerpan wrote: > Of course, these days, there's a version of troff that borrows TeX's > layout rules, while also adding vastly improved font handling, support > for the most useful/widely used groff extensions, and more. Why Heirloom > troff isn't more widely used is a puzzle for the ages. > No matter how far you tart up the former, Troff and TeX just aren't playing the same ballgame. --T > Mike >

8 years, 4 months

Steven Bourne - early days of unix talk

by arnold＠skeeve.com

>From the 9fans list: https://www.youtube.com/watch?v=2kEJoWfobpA It's about an hour long; haven't watched it yet. Arnold

8 years, 4 months

editors passim

by Steve Simon

Another one i would be interested to know more of. whilst at college i used an inter data 3210 running edition 7, which was version 7 with bits of 2.1 bsd (very much from memory). there was an editor on that machine i have never seen or heard of since - le. it was a visual editor, and i think supported multiple windows, of termcap style. anyone know more? -Steve

8 years, 4 months

The QED editor, and its modern versions

by Christian Neukirchen

While we are on the topic of old Unix editors, I once made Caltech qed build again: https://github.com/chneukirchen/qed-caltech Also, I've been trying to contact David Tilbrook, who maintains(-ed?) his own version of qed, without success. I got an evaluation copy of his QEF build system, which contains a bit of documentation about it, but no binary. Perhaps someone here can help out, or knows more? -- Christian Neukirchen <chneukirchen(a)gmail.com> http://chneukirchen.org

8 years, 4 months

UK written UNIX line editor in early 80s?

by Steve Mynott

In the autumn of 1984 as an undergrad at Durham University (UK) I remember using a Pascal compiler (pc) on a BSD4.1 system (bumped after several months to 4.1c and running I would guess on a small VAX?) and using a strange line editor (probably because the terminal had crude screen handling capabilities?). I can't remember much about it other than it seemed to resemble ex. I think I was told it was written in the UK and doing some Googling suggests it may have been "em" (Editor for Mortals) from Queen Mary College. However, the time frame for that editor was late 70s and it would have been quite old by 1984. So my current theory is that it was a fork (maybe with a different name) or later version? Anyone use this editor or anything similar around 1984? -- 4096R/EA75174B Steve Mynott <steve.mynott(a)gmail.com>

8 years, 4 months

The Rand Editor

by ron minnich

is this code lost or out there somewhere?

8 years, 4 months

BSD 4.2 distribution differences

by Arthur Krewat

Hello all... I have a BSD 4.2 distribution that I imaged a few years back. It differs from the one in Warren's archives in subtle but significant ways. It appears to be a few months earlier than the one at: http://www.tuhs.org/Archive/Distributions/UCB/4.2BSD/ Case in point, from srcsys.tar: diff -r ./GENERIC/vers.c /home/krewat/archive/unix/tuhs/4BSD/Distributions/4.2BSD/bin/srcsys/GENERIC/vers.c 1c1 < char version[] = "4.2 BSD UNIX #8: Sun Oct 2 12:03:09 PDT 1983\n"; --- > char version[] = "4.2 BSD UNIX #9: Wed Nov 2 16:00:29 PST 1983\n"; or from src.tar: diff -r ./bin/mail.c /home/krewat/archive/unix/tuhs/4BSD/Distributions/4.2BSD/bin/src/bin/mail.c 2c2 < static char sccsid[] = "@(#)mail.c 4.18 (Berkeley) 9/9/83"; --- > static char sccsid[] = "@(#)mail.c 4.21 (Berkeley) 11/1/83"; 449,454d448 < if (strcmp(my_name, "root") && < strcmp(my_name, "daemon") && < strcmp(my_name, "network")) { < usage(); < done(); < } (was doing a diff -r of the entire tree) stand (first file on tape) is the same down to the checksum. But the checksum for every other file (tape files, not individual files) on the tape is different. Also weird is that on my distribution, these exist: < -rwxrwxr-x 0/10 0 Jul 26 16:37 1983 ./ucb/lisp/doc/ < -r--r--r-- 0/10 3522 Jul 26 03:08 1983 ./ucb/lisp/doc/lmacs < -r--r--r-- 0/10 5196 Sep 25 21:01 1983 ./ucb/lisp/doc/ch0.n < -r--r--r-- 0/10 13713 Sep 25 21:01 1983 ./ucb/lisp/doc/ch1.n < -r--r--r-- 0/10 42144 Sep 25 21:01 1983 ./ucb/lisp/doc/ch2.n < -r--r--r-- 0/10 9278 Jul 26 03:09 1983 ./ucb/lisp/doc/ch3.n < -r--r--r-- 0/10 34324 Sep 25 21:01 1983 ./ucb/lisp/doc/ch4.n < -r--r--r-- 0/10 18913 Jul 26 03:10 1983 ./ucb/lisp/doc/ch5.n < -r--r--r-- 0/10 21543 Sep 25 21:01 1983 ./ucb/lisp/doc/ch6.n < -r--r--r-- 0/10 162 Jul 26 03:10 1983 ./ucb/lisp/doc/ch61.n < -r--r--r-- 0/10 19093 Jul 26 03:10 1983 ./ucb/lisp/doc/ch7.n < -r--r--r-- 0/10 26713 Sep 25 21:01 1983 ./ucb/lisp/doc/ch8.n < -r--r--r-- 0/10 12914 Jul 26 03:11 1983 ./ucb/lisp/doc/ch9.n < -r--r--r-- 0/10 8107 Jul 26 03:11 1983 ./ucb/lisp/doc/ch10.n < -r--r--r-- 0/10 8694 Sep 25 21:01 1983 ./ucb/lisp/doc/ch11.n < -r--r--r-- 0/10 22170 Jul 26 03:12 1983 ./ucb/lisp/doc/ch12.n < -r--r--r-- 0/10 11453 Jul 26 03:12 1983 ./ucb/lisp/doc/ch13.n < -r--r--r-- 0/10 6678 Jul 26 03:12 1983 ./ucb/lisp/doc/ch14.n < -r--r--r-- 0/10 6368 Jul 26 03:12 1983 ./ucb/lisp/doc/ch15.n < -r--r--r-- 0/10 36465 Jul 26 03:13 1983 ./ucb/lisp/doc/ch16.n < -r--r--r-- 0/10 6301 Jul 26 03:13 1983 ./ucb/lisp/doc/chb.n < -r--r--r-- 0/10 4364 Jul 26 03:13 1983 ./ucb/lisp/doc/chc.n < -r--r--r-- 0/10 5700 Jul 26 03:13 1983 ./ucb/lisp/doc/Makefile < -r--r--r-- 0/10 12 Jul 26 03:13 1983 ./ucb/lisp/doc/indexsed < -r--r--r-- 0/10 98 Jul 26 03:13 1983 ./ucb/lisp/doc/mantags < -r--r--r-- 0/10 166 Jul 26 03:13 1983 ./ucb/lisp/doc/extrnames.awk < -r--r--r-- 0/10 94 Jul 26 03:13 1983 ./ucb/lisp/doc/fixmks.sed < -r--r--r-- 0/10 57142 Jul 26 03:14 1983 ./ucb/lisp/doc/franz.n But in the TUHS version, ./usb/lisp/doc is linked to /usr/doc/lisp - which doesn't seem to exist. These are just examples of what I see and not the only differences.

8 years, 4 months

4.3 Wisc file transfer

by Mary Ann Horton

Apologies if this is already on the list somewhere. What's the best way to transfer files in and out of the simh 4.3BSD Wisc version? I can do it with tape files, but it seems like FTP or ssh or NFS ought to be possible, and none is behaving at first blush. Also, what's the recommended way to shut down the system? I shutdown now to single user, then sync a few times, then ^E, but when I boot again I get fsck errors serious enough to require a manual fsck (which generally works fine.) Thanks, Mary Ann

8 years, 4 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS