TUHS

tuhs@tuhs.org

64 participants
6514 discussions

by Mark Longridge

Firstly, I should mention I'm using simh to simulate Unix version 5. Well I tried to reorganize the files in unix v5. Mainly I wanted more room on rk0 so I figured I'd create a new drive and put all the source from /usr/source/s1 on it. The first problem I had was I couldn't just cp over all the /usr/source/s1 files to the new drive because of "Arg list too long" so I figured I would just create an archive file called all.a which would include all the files in /usr/source/s1 and copy that over. But then I got "phase error" when I tried to keep adding files to the archive (I had to do this in stages, e.g. ar r all.a /usr/source/s1/a* then ar u all.a /usr/source/s1/b* etc). Phase error seemed to occur when the archive got larger than around 160,000 bytes. So I ended up creating 3 archive files to keep from getting "phase error". I was wondering does anyone understand what the limits are for the cp and ar commands? Mark

10 years, 9 months

Re: [TUHS] Unix taste

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy <doug(a)cs.dartmouth.edu> > Yet a quoted "wc -l" as a bare command or (I suspect) as the first > command in a pipeline would lead to "command not found". I don't know about earlier versions of Unix, but FWLIW on V6 it does indeed barf in both of these cases (just tried it). Noel

10 years, 9 months

Re: [TUHS] Unix taste

by Doug McIlroy

Thanks, Norman, for reminding me of the actual pipe syntax in v3. This reinforces the title of one history item on Dennis's website: "Why Ken had to invent |". I'd suppressed all memory of the fact that in the pipeline ... > cmd > ... cmd had to be a single token. That was certainly not the intent of my original proposal. It is understandable, though, as a minimal hack to the existing shell syntax and its parser, which accepted occurrences of <token and >token anywhere in a command. The single-token rule meant that, if you wanted to supply an option to wc in the pipeline ls > wc > you couldn't write ls > wc -l > as one would expect, but instead had to write ls > "wc -l" > Yet a quoted "wc -l" as a bare command or (I suspect) as the first command in a pipeline would lead to "command not found". What a mess! Soon after, Ken was inspired to invent the | operator, lest he should have to describe an ugly duckling in public at an upcoming symposium in London. Is it possible that the ugliness of the token hack was the precipitating factor that gave us the sublime | ? But for the hack, perhaps we'd still be writing ls > wc > Doug

10 years, 9 months

Re: [TUHS] alloc.s is missing from unix v5

by jnc＠mercury.lcs.mit.edu

> From: Mark Longridge <cubexyz(a)gmail.com> > In Unix v6 there is a file in the TUHS archives > V6/usr/source/s4/alloc.s > .. > In v5 the command "ar t /lib/libc.a" lists the files in the c library > and that includes alloc.o Well, at least you have the binary. Dis-assembly time! :-) > so there should be a source file somewhere. Ha-ha-ha-ha-HAH! You _are_ an optimist! I'm not joking about the dis-assembly. Not to worry, it's not too bad (I had to do it to retrieve the source for the V6 RL bootstraps - and you've got symbols too), and you've got the V6 alloc.s to guide you - with luck, it did not get re-written between V5 and V6, and you may have minimal (no?) changes to deal with? I don't know which debugger V5 has (db or cdb); if neither, you can spin up a V6 and do the disassembly there. Do "db alloc.o > alloc.s" and then type '0?<RETURN>' followed by a whole bunch of RETURNs. (You can do plain 'db alloc.o' first, to see about how many CR's you need.) Next do a "nm alloc.o" to get as many symbols as you can. At that point, I would extract your prototype alloc.s from the emulated machine so you can use a real editor to work on it. (You should have a way to get files in and out of the simulated machine; that was one of the first things I did with my V6 work: http://www.chiappa.net/~jnc/tech/V6Unix.html although if you're using SIMH I don't know if that has a way to import files - a big advantage to using Ersatz-11, although one I didn't know about when I picked it.) You may need to go back and do a "xxx/" {with appropriate value for "xxx"} plus a few CR's to get static constants, but at that point you should have all the raw data you need to re-create the V5 alloc.s. Obviously, start by having your proto-allocV5.s in one window, and compare with the allocV6.s in another... like I said, you may luck out. The final step, of course, is 'as alloc.s', and then 'cmp a.out alloc.o'. Noel

10 years, 9 months

Re: [TUHS] terminal - just for fun

by Doug McIlroy

> Interesting that they had both - I don't remember hearing about the 37 > but that doesn't mean much. :-) The only model 33 on any PDP11 in Bell Labs research was the console. Otherwise all terminals were ASCII devices. Model 37's predated Unix. doug

10 years, 9 months

alloc.s is missing from unix v5

by Mark Longridge

Ok, I was trying to understand exactly what the alloc(III) subroutine does in unix version 5 and I've discovered that the source code for it appears to be missing. In Unix v6 there is a file in the TUHS archives V6/usr/source/s4/alloc.s so I assume there should be a V5/usr/source/s4/alloc.s as well but I can't find it anywhere. In v5 the command "ar t /lib/libc.a" lists the files in the c library and that includes alloc.o so there should be a source file somewhere. Mark

10 years, 9 months

Re: [TUHS] Unix taste (Re: terminal - just for fun)

by norman＠oclsc.org

Davwe Horsfall: I was surprised when "chdir" became "cd", but I suppose it fits the philosophy of 2-letter commands. ====== Don't forget that the original spelling, in the PDP-7 UNIX that had no published manual, was ch. The 1/e manual spells it chdir. I remember that in one of Dennis's retrospective papers, he remarks on the change, and says he can't remember why. I once asked in the UNIX room if anyone could recall why ch changed to chdir. Someone, I forget who, suggested it was because the working directory was the only thing that could be changed: no chmod or chown in the PDP-7 days. I don't know whether that's true. Norman Wilson Toronto ON

10 years, 9 months

Re: [TUHS] Unix taste (Re: terminal - just for fun)

by norman＠oclsc.org

Lyndon Nerenberg: Do you still consider '^' the shell's inter-command pipe character? ====== No. By the time I first used UNIX, | was well-established as the official pipeline character; ^ was just a quirky synonym. I had the impression somehow that ^ was there just to make life easier on the Model 33 Teletype, which had no | key. Digging into old manuals, ^ and | appear simultaneously, in sh(1) in the Fourth Edition. Pipelines first appeared in 3/e, though with a clumsier syntax (not supported by any current shell I know): where we would now type ls | wc the original syntax was ls > wc > The trailing > was required to tell the shell to make a pipeline of the two commands, rather than to redirect output to a file named wc. One could of course redirect the final command's output to a file as well: ls > wc > filecount Even clumsier: where we would now type ls | pr -h 'Look at all these files!' the 3/e shell expected ls > "pr -h 'Look at all these files!'" > because its parser bound > to only the single following word. The original syntax could be reversed too: wc < ls < The manual implies this was required if the pipeline's ultimate input came from a file. Maybe someone with more energy than I have right now can dig out the source code and see. I was originally going to use an example like who | grep 'r.*' | wc -l but the old-style version would be anachronistic. There was no grep yet in 3/e, and wc took no arguments. I do still have the habit of quoting ^ in command arguments, but that's still necessary on a few current systems; e.g. /bin/sh on Solaris 10. Fortunately, that makes it easier to remember to quote ! as well, something required by the clumsy command-history mechanism some people like but I don't. (I usually turn off history but occasionally it gets turned on by accident anyway.) Norman Wilson Toronto ON

10 years, 9 months

changes for modern -> v7 -> v6 -> v5

by Mark Longridge

>> From: Mark Longridge <cubexyz(a)gmail.com> >> I thought you folks might be interested in looking at the changes I had >> to make. It was a bit harder than the port to v6 but porting to v6 >> first did make things a bit easier. > To save me from poring over 'diff' output :-), what (at a high level) were > the changes you had to make to get it to run on v5? > Noel Briefly the differences were these: modern to v7: remove all references to void no vi on v7, v6, and v5 so using ed instead. no conditional compilation so no way to make a truly universal version which works on everything. v7 to v6: use iolib instead of stdio: fopen -> copen, fclose -> cclose, fgetc -> cgetc, fputc -> cputc use int (no long or short in v6) call to srand uses different argument copen returns an int instead of a file pointer no strcat in v6 so the function had to be added v6 to v5: no iolib: fopen -> creat + open, copen -> open, cgetc -> read, cputc -> write, cclose -> close no scanf in v5 so I used the source for gets from v7 instead getchar() leaves a newline in the buffer so I added an extra call to getchar() immediately before each call to gets The size of the unirubik executable was 8K for modern Linux, 10K for v7, 10K for v6, and 5492 bytes for v5. Generally I was a lot slower trying to edit files with ed rather than vi but I'm a lot better with ed now. There wasn't really much unix v5 code to look at and I found the v5 manual a bit spartan. Mark

10 years, 9 months

terminal - just for fun

by Tim Newsham

just for fun, you might want to run your ancient unix in simh using this terminal: https://github.com/Swordifish90/cool-old-term -- Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com

10 years, 9 months

Re: [TUHS] Unix taste (Re: terminal - just for fun)

by Norman Wilson

Larry McVoy: Looking at git like that is sort of like looking at the size of a dynamically linked app. Ya gotta add in libc and all the extensions people use to make it not suck. ===== In which case one should also add the size of the kernel, or at least the code paths exercised by a given program. Not to mention the layers of window systems, networking, desktops, message buses, name-space managers, programs to emulate 40-year-old terminal hardware, flashy icons, and so on. I say all this to underscore Larry's point, not to dispute it. Everything has gotten more complicated. Some of the complexity involves reasonable tradeoffs (the move toward replacing binary interfaces with readable text where space and time are nowhere near critical, like the /proc and /sys trees in modern Linux). Some reflects the more-complex world we live in (networking). But a lot of it seems, to my mind that felt really at home when it first settled into UNIX in 1981, just plain tasteless. There are certainly legitimate differences in aesthetic taste involved, though. I think taste becomes technically important when it can be mapped onto real differences in how easily a program can be understood, whether its innards or its external interface; how easily the program can adapt to different tasks or environments; and so on. Norman Wilson Toronto ON

10 years, 9 months

Re: [TUHS] terminal - just for fun

by Norman Wilson

Tim Newsham: I was referring to the bell labs guys who wrote linux and later plan9... ======= Which Bell Labs guys wrote Linux? I assume you're not referring to Andy Tanenbaum, erstwhile teacher of a certain famous Finn ... Norman Wilson Toronto ON PS: it's true that the Plan 9 folks at Bell Labs were early champions of both Unicode and the UTF-8 encoding. Source: personal memory.

10 years, 9 months

Re: [TUHS] terminal - just for fun

by Doug McIlroy

> Remember that writing programs on terminals was a relative latecomer -- > FORTRAN was designed for punched cards. Remember that FORTRAN also was a latecomer. It was a shock to convert from the full character set of the Flexowriters at Whirlwind to the rebarbative upper-case-only of the 704. In that vein, there was a period when the Chicago Manual Style disparaged uppercase text, with an exception being made for computer programs, which of course should be presented in upper case. Doug

10 years, 9 months

Subject: changes for modern -> v7 -> v6 -> v5

by Doug McIlroy

> no conditional compilation so no way to make a truly universal version > which works on everything. If cc -I is there, it should be able to do the tailoring. Also conditional compilation of non-declaration statements can be replaced by regular if statements that typically can be optimized away (though the old C compilers may not do so). Incidentally, I would say that the use of conditional compilation is evidence that the code is NOT truly universal, but has to be specially adapted to various environments. Doug

10 years, 9 months

Re: [TUHS] Unix style

by Doug McIlroy

> "Reining in", please (peeve, peeve) Ouch. Doubly so for the erstwhile curator of "spell". (COuld "reigning in" somehow have been implanted by this headline that I saw in The Economist a few days ago: "The reign in Maine is easy to explain"?) Doug

10 years, 9 months

Re: [TUHS] Unix taste (Re: terminal - just for fun)

by jnc＠mercury.lcs.mit.edu

> From: "A. P. Garcia" <a.phillip.garcia(a)gmail.com> > the spirit of emacs without the bloat :-) Exactly. I've often wondered what the heck exactly it is that GNU Emacs, GCC, etc are all doing with those megabytes of code. (In part, probably all those options: "Options. We've got lots of them. So many in fact, that you need two strong people to carry the documentation around.", as that classic hack says. But there's no way the options alone can explain it all.) The thing is that it's not just aesthetics that makes large programs bad; there are very good practical reasons why they are bad, too. The 'takes more resources' isn't such a big deal today, because memory is massive, and there's a ton of computing power to be thrown at things. (Although I'm always amazed at how the active content in Web pages seems to run incredibly slowly on all but the very latest and greatest machines. WTF are they doing?) But more code = more material that someone new has to understand before they can make some change (and long-lived code is always being changed/upgraded by new people). And when people understand a system poorly, their changes tend to be 'a bag on the side', and that's the kind of 'code cancer' that tends to kill systems in the long run. More code also is also more places where there can be bugs (especially when it's changed by someone who understands it poorly, repeat previous comment). Etc, etc. And those will never go away - human brain power is finite, and unlike hardware, not expanding. There's just no reason to have N megabytes of code when .N will do. (I've often thought we ought to make new programmers serve an apprenticeship of a year of two on a PDP-11 - to teach them to 'think small', and to realize you _can_ do a lot in a small space.) Noel

10 years, 9 months

Unix taste (Re: terminal - just for fun)

by norman＠oclsc.org

Doug McIlroy: A symptom of why I have always detested emacs and vi. With ^D, ^C, and ^\, Unix has more than enough mystery chords to learn. ==== What is this ^C mystery chord? Or can it be that I am actually more wedded to the past than Doug, in that I still use DEL as my interrupt character? And, for that matter, @ for kill (though in the modern world one has to type @ often enough to require learning a different modern-world mystery chord, ^V). I break with the past for character-erase, though: backspace, not #. Norman Wilson Toronto ON

10 years, 9 months

Re: [TUHS] Unix taste (Re: terminal - just for fun)

by jnc＠mercury.lcs.mit.edu

> From: John Cowan <cowan(a)mercury.ccil.org> > because of all the Elisp code it ships with So why is /usr/bin/emacs 4.5 megabytes? > That's basically just the kind of peeving that objects to the use of > computers as calculators and spelling checkers. I just gave several good reasons why large programs (well, technically, systems) are bad. Are you saying those reasons are fallacious? Noel

10 years, 10 months

Re: [TUHS] unirubik port to unix v5 is complete

by jnc＠mercury.lcs.mit.edu

> From: Mark Longridge <cubexyz(a)gmail.com> > I thought you folks might be interested in looking at the changes I had > to make. It was a bit harder than the port to v6 but porting to v6 > first did make things a bit easier. To save me from poring over 'diff' output :-), what (at a high level) were the changes you had to make to get it to run on v5? Noel

10 years, 10 months

Re: [TUHS] Unix taste (Re: terminal - just for fun)

by jnc＠mercury.lcs.mit.edu

> From: "A. P. Garcia" <a.phillip.garcia(a)gmail.com> > Being so small, I expected the editor to lack a scripting language. Well, there is a companion 'compiler' which converts extension source into the intermediate form (byte-code) which is interpreted by the editor. But it's even smaller (67KB!) and as fast as the editor itself. > I was pleasantly surprised that it does have one, and that it's a c > derivative ... "Extensible and modifiable" doesn't always mean the same > thing to everyone, and well, you're a kernel hacker. Take a quick look at a source file, e.g. one of mine: http://ana-3.lcs.mit.edu/~jnc/tech/cmd.e and you'll see i) what it's like (except for a few new editing-specific keywords, such as 'on <key>' in function definitions, it's pretty much C), and ii) it will give you a sense of the kind of things one writes in it, and how easy it is to do so. The underlying run-time basically just provides buffer, display, etc primitives, and pretty much all the actual editor commands are written in the 'extension' languge, even simple things like 'forward character' (^F), etc. The complete manual is available online, the run-time system is described here: http://www.lugaru.com/man/Primitives.and.EEL.Subroutines.html Epsilon comes (as of a few versions back, I haven't bothered to upgrade) with about 22K lines of source, which is the bulk of the actual editor; that turns into about 190KB of intermediate code. Noel

10 years, 10 months

unirubik port to unix v5 is complete

by Mark Longridge

Hi folks, I finally managed to get unirubik working on unix v5. I thought you folks might be interested in looking at the changes I had to make. It was a bit harder than the port to v6 but porting to v6 first did make things a bit easier. I've included links to all three versions. unirubik.c.v5 needs gets.c http://www.maxhost.org/other/unirubik.c.v7 http://www.maxhost.org/other/unirubik.c.v6 http://www.maxhost.org/other/unirubik.c.v5 http://www.maxhost.org/other/gets.c The unirubik for v5 was considerably smaller than the other versions, a mere 5492 bytes. Mark

10 years, 10 months

Re: [TUHS] terminal - just for fun

by Dave Horsfall

On Sat, 2 Aug 2014, John Cowan wrote: > > Hadn't really noticed; I went straight from CP/M to Unix, giving > > MS-DOS a miss. > > I was actually thinking about OS/8 and RT-11. Ahh... RT-11 and TECO... Who here hasn't typed their name into it to see what it did? I was thinking of home systems. -- Dave

10 years, 10 months

Re: [TUHS] Unix taste (Re: terminal - just for fun)

by jnc＠mercury.lcs.mit.edu

> From: Benjamin Huntsman <BHuntsman(a)mail2.cu-portland.edu> > I thought it stood for Escape-Meta-Alt-Control-Shift :) > From: Dave Horsfall <dave(a)horsfall.org> > EMACS - Editor too large Those are both pretty funny! BTW, Epsilon (that 250KB Emacs that I was raving about) not only runs under Windows, it also runs under Linux, Mac OS, FreeBSD, etc. Here: http://lugaru.com/ I can't say enough good things about it (hence my 30-year addiction to it). If you want an Emacs clone that is very small; very fast; and wildly extensible and modifiable (it comes with almost all the source), in C (effectively); this is the one. Noel

10 years, 10 months

Unix taste (Re: terminal - just for fun)

by Doug McIlroy

> To each their own. Indeed. > As a Vi user, nothing beats having Esc on the home row. A symptom of why I have always detested emacs and vi. With ^D, ^C, and ^\, Unix has more than enough mystery chords to learn. Emacs and vi raised that number to a high power--an interface at least as arcane and disorganized as the DD card in OS 360--baroque efflorescences totally out of harmony with the spirit of Unix. (Perhaps one could liken learning vi to learning how to finger the flute, but the flute pays off with beautiful music. To put the worst face on vi, it "pays off" only by promoting frantic tinkering.) A modern-day analog of the undisciplined exuberance of emacs and vi: for a good time on linux try less --help | wc Does comment on taste belong in a discussion of history? I think so. Unix was born of a taste for achieving big power by small means rather than by unbounded accumulation of facilities. But evolution, including the evolution of Unix, does not work that way. An interesting question is how the corrective of taste manages ever to recenter the exuberance of evolution. The birth of Unix shows it can happen. When will it happen again? Can one cite small-scale examples that gained traction within the larger evolution of Unix? Doug

10 years, 10 months

Re: [TUHS] Unix taste (Re: terminal - just for fun)

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy <doug(a)cs.dartmouth.edu> > A symptom of why I have always detested emacs and vi. With ^D, ^C, and > ^\, Unix has more than enough mystery chords to learn. Emacs and vi > raised that number to a high power--an interface at least as arcane and > disorganized as the DD card in OS 360--baroque efflorescences totally > out of harmony with the spirit of Unix. I will agree that the Emacs user interface is not simple - although there are levels, and one can start out e.g. without knowing the commands to move by word, and get by with the commands to move by character - and of course nowadays, the arrows, etc, keys on keyboards are bound to the appropriate commands, for novices. But it's a subtle debate; yes, it's not for everyone, but i) as an application, not everyone has to use it (unlike a kernel), and ii) as the editor is the principal tool which most programmers spend hours a day using, it is not insensible to have a more complex but powerful tool which takes a while to fully master. (Like playing a violin...) Back on V6, we started using one written by someone at BBN (memory fails me as to exactly who), and it improved my productivity immensely (with 'WYSIWG' editing - i.e. you always see the current contents of the buffer, multiple buffers, multiple windows, etc). I had been using 'ed' (although I had access to Emacs on the ITS machines), and although I was (and remain) fairly skilled at 'ed', the factors I just listed are immense, IMO. Being able to see the code as I work on it really, really helps (for me, at least). But a lot of that is orthogonal to Emacs command interface; you can have 'WYSIWYG', multiple buffers, etc with a wholly different command interface, and get much the same benefit. (E.g. uSoft Word has most of those; real WYSIWG [i.e. with multiple fonts], multiple files open at once, etc, etc.) Does something like Word produce the same reaction for you? I don't use it much, but my wife does (she's an engineer, and uses it to write papers), and its complexity drives her crazy sometimes. As for the size of Emacs, everyone needs to distinguish between GNU Emacs, and Emacs-like editors. Just as GCC is a beast, but other C compilers are and were much smaller, there are small Emacses out there. Back on V6 (on a PDP-11, of course), it had to fit into 64KB; the one we used didn't have the kind of extensibility common in them now, but it was still a much better tool for me than 'ed'. As I recall the performance was pretty good (albeit it chewed CPU time, since it woke up on every character - Multics had an Emacs which tried to avoid that, and only woke up on non-printing characters, and used system echoing for the others). I don't know for sure (I don't have the source to hand at the moment - that's one of the things I hope to recover if/when I can read those backup tapes), but I suspect that it 'windowed' files (i.e. didn't read the whole thing in); with the 65KB address space of the 11, that would be almost inevitable. I have been using another Emacs, Epsilon, for almost 30 years now; it started as basically Emacs for MS-DOS, and later became Emacs for Windows, and it is small and very fast. The Windows executable is about 250KB, and it loads a 'state file' (mostly interpreted 'compiled' intermediate code, written in something that's 99.2% 'C', in which a lot of the editor is actually written) of about 200K (for mine, which has a lot of extensions I wrote). It starts fast, and runs blindingly fast. It also uses the file 'windowing' techniques, and can handle much larger files than its address space (this dates back to its MS-DOS days). So Emacs != big (at least, not necessarily). > A modern-day analog of the undisciplined exuberance of emacs and vi: > for a good time on linux try I basically agree with you on this; I want to go away and collect my thoughts before responding, though. Noel

10 years, 10 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