TUHS

tuhs@tuhs.org

61 participants
6532 discussions

3B20S UNIX User's Manual Release 4.1 Scans Thread

by segaloco

Good evening folks. I'm starting a new thread to pass along info as I scan materials from the 3B20S manual that I picked up. I figured it'd be easier to trickle out the bits folks ask me for first and then continue to scan the rest, that way anyone looking to sink their teeth into something specific can be sated first. With that, the first scan (and frankly one of my favorite things about this manual) is the cover itself: https://commons.wikimedia.org/wiki/File:UNIX4.1UsersManualCover.png Someone had mentioned the idea of making this into a poster and I gotta say, I'd gladly put one up. The image definitely would need some cleanup for that, I just scanned it like it came, haven't tried to clean up any of the wear of time yet. Sadly, the back cover isn't emblazoned with a big Bell logo like the 3.0 and 5.0 (Bell variant) manuals, so scanning that would be a boring white piece of cardstock. Anywho, the next round which may come later this evening or sometime this weekend is going to be various *ROFF-related documents, so documents like troff(1), mm(5), etc. - Matt G.

2 years, 6 months

Re: UNIX on (not quite bare) System/370

by jnc＠mercury.lcs.mit.edu

> From: Bakul Shah > Is there a publicly available description of Reiser's VM system? I > found "A Unix operating system for the DEC VAX 11/780 Computer" by > London & Reiser which includes a long paragraph on VM (included below) That para is basically all about the VAX paging hardware; it doesn't say anything about how that (any :-) Unix actually uses it. Noel

2 years, 6 months

Stdin Redirect in Cu History/Alternatives?

by segaloco

Good morning all. I've been doing some historical research on the UUCP cu utility this morning and have come across a little discrepancy between the various UNIX streams I was wondering if someone could illuminate. So cu as of V7 supported the ~$ escape, a means of calling a local procedure and emitting stdout over the TTY line to the remote machine, all fine and good for packaging a character stream to emit. However, what I'm not finding in that age of documentation is any means of requesting std*in* from the TTY line as input to a local procedure (in essence running a text filter or handshake-driven protocols over cu). The context in which I'm researching this is integrating cu into my bare-metal SBC programming using XMODEM so I can rest a little easier my process is based on tools I'll probably find in most places. So old fashioned Mike Lesk-era cu only seems to do stdout redirect, but no stdin. I did some further digging and it looks like different UUCP implementations cracked this nut with different escapes, with BSD eventually going with ~C and Taylor UUCP opting for ~+. Checking the current illumos manual pages (for a SVR4-ish example) doesn't turn up any command for this. This is indicative of there never being an agreed-upon mechanism for doing this, although I could see this being a very useful mechanism. What I'm curious about is if the lack of a bi-directional redirect in early cu is reflective of a lack of need for that sort of functionality at the time or that matters such as that were handled through a different mechanism. One thought I did have is that there wasn't file locking at the time (right?) and so theoretically nothing would prevent one from using a cu session on one terminal to send interactive commands and then a second using fd redirects in the shell to run filters/protocols separately of the interactive stream. - Matt G.

2 years, 6 months

Re: pre-1991 USENIX proceedings

by Marc Donner

https://bitsavers.org/pdf/usenix/USENIX_1986_Winter_Technical_Conference_Pr… Here is the URL (All I did was search for ‘“Unix on big iron” usenix proceedings’) On Mon, Dec 19, 2022 at 4:59 PM James Frew <frew(a)ucsb.edu> wrote: > Hello Marc, > > Where did you find the 1986 USENIX proceedings? > > Reason I'm asking is, I have a pile of pre-1991 USENIX proceedings that I > haven't found online, and I'm planning to get them scanned. It would be > great if I didn't have to go the trouble :-) > > Thanks, > /James Frew > On 2022-12-19 13:36, Marc Donner wrote: > > > There was a track of USENIX 1986 called "UNIX on Big Iron." Peter Capek > of IBM was the chair and Gene Miya and Jim Lipkis rounded out the program > committee. The proceedings are available. > > -- ===== nygeek.net mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>

2 years, 6 months

Re: origin of null-terminated strings

by Douglas McIlroy

> To what extent were the Unix folks at Bell Labs already familiar with DEC systems before the PDP-7? Some awareness, but no hands-on experience, > was any thought given to trying to get a 360 system? Very serious thought. However, virtual memory was a non-negotiable desideratum, to which Gene Amdahl was implacably opposed because demand paging would devastate hardware performance. Soon after GE got the nod, IBM revealed Gerrit Blaauw's skunk-works project, the 360/67, but by then the die had been cast. Michigan bought one and built a nice time-sharing system that was running well before Multics. Doug

2 years, 6 months

origin of null-terminated strings

by Douglas McIlroy

I think this cited quote from https://www.joelonsoftware.com/2001/12/11/ is urban legend. Why do C strings [have a terminating NUl]? It’s because the PDP-7 microprocessor, on which UNIX and the C programming language were invented, had an ASCIZ string type. ASCIZ meant “ASCII with a Z (zero) at the end.” This assertion seems unlikely since neither C nor the library string functions existed on the PDP-7. In fact the "terminating character" of a string in the PDP-7 language B was the pair '*e'. A string was a sequence of words, packed two characters per word. For odd-length strings half of the final one-character word was effectively NUL-padded as described below. One might trace null termination to the original (1965) proposal for ASCII, https://dl.acm.org/doi/10.1145/363831.363839. There the only role specifically suggested for NUL is to "serve to accomplish time fill or media fill." With character-addressable hardware (not the PDP-7), it is only a small step from using NUL as terminal padding to the convention of null termination in all cases. Ken would probably know for sure whether there's any truth in the attribution to ASCIZ. Doug

2 years, 6 months

Re: origin of null-terminated strings

by jnc＠mercury.lcs.mit.edu

> From: Bob Supnik > The PDP11 had .ASCIZ, starting with Macro11 in 1972. I was just about to report on my results, after a tiny bit of digging, which included this. The important datum is that PAL-11 (in DEC-11-GGPB-D, "paper tape software", April 1970, revised March 1971), which _preceded_ Macro-11, _does not_ include .ASCIZ (although it has .ASCII). My oldest Macro-11 book (DEC-11-OMACA-B-D, "BATCH-11/DOS-11 Assembler (MACRO-11)", April 1972, revised March 1973) does have .ASCIZ. So in the DEC PDP-11 universe, it dates from sometime between 1970 and 1972. I'm not sure if Bell had any of the DEC paper tape software: "In early 1970 we proposed acquisition of a PDP-11, which had just been introduced by Digital. ... an order for a PDP-11 was placed in May. The processor arrived at the end of the summer, but the PDP-11 was so new a product that no disk was available until December. In the meantime, a rudimentary, core-only version of Unix was written using a cross-assembler on the PDP-7." So the .ASCIZ in Macro-11 wasn't until a couple of years later. Noel

2 years, 6 months

Terms for string, and similar character constructs (was: origin of null-terminated strings)

by Alejandro Colomar

[Resend from my subscribed address, as the list is subscribers-only, it seems] In C, most syscalls and libc functions use strings, that is, zero or more non-NUL characters followed by a NUL. However, there are a few cases where other incompatible character constructs are used. A few examples: - utmpx(5): Some of its fields use fixed-width char arrays which contain a sequence of non-NUL characters, and padding of NULs to fill the rest (although some systems only require a NUL to delimit the padding, which can then contain garbage). - Some programs use just a pointer and a length to determine sequences of characters. No NULs involved. - abstract sockets: On Linux, abstract Unix socket names are stored in a fixed-width array, and all bytes are meaningful (up to the specified size), even if they are NULs. Only special that that the first byte is NUL. Since those are only rare cases, those constructs don't seem to have a name; some programmers call them strings (quite confusingly). Has there been any de-facto standard (or informal naming) to call those things, and differentiate them? Thanks, Alex -- <http://www.alejandro-colomar.es/>

2 years, 6 months

Please reinstate

by Aaron

I accidentally unsubscribed Sent from my iPhone

2 years, 6 months

Continued celebration of Warren's Flame

by Will Senn

All, I recently migrated my blog - it's new and improved, of course:) over to https://decuser.github.io. When I saw Warren was awarded Usenix's "The Flame" last week, I thought it appropriate that one of my first new blog posts celebrate Warren and his well deserved award. Here's the post: https://decuser.github.io/unix/2022/12/15/usenix-flame-award-2022.html Thanks again to Warren, both for the initiative, and for the maintenance of one of my all time favorite archives. Thanks, Will

2 years, 6 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