TUHS

tuhs@tuhs.org

6532 discussions

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