Notably: 32v_usr.tar.gz and sys3.tar.gz. I’ve not unpacked the tar files. If someone would like more detail about the contents I’ll produce a TOC offline for them.
David
As a result of the recent discussion on this list I’m trying to understand the timeline of graphical computing on Unix, first of all in my preferred time slot ’75 -’85.
When it comes to Bell Labs I’m aware of the following:
- around 1975 the Labs worked on the Glance-G vector graphics terminal. This was TSS-516 based with no Unix overlap I think.
- around the same time the Labs seem to have used the 1973 Dec VT11 vector graphics terminal; at least the surviving LSX Unix source has a driver for it
- in 1976 there was the Terak 8510; this ran primarily USCD pascal, but it also ran LSX and/or MX (but maybe only much later)
- then it seems to jump 1981 and to the Blit.
- in 1984 there was MGR that was done at Bellcore
Outside of the labs (but on Unix), I have:
- I am not sure what graphics software ran on the SUN-1, but it must have been something
- Clem just mentioned the 1981 Tektronix Magnolia system
- Wikipedia says that X1 was 1984 and X11 was 1987; I’m not sure when it became Unix centered
- Sun’s NeWS arrived only in 1989, I think?
Outside of Unix, in the microcomputer world there was a lot of cheap(er) graphics hardware. Lot’s of stuff at 256 x 192 resolution, but up to 512 x 512 at the higher end. John Walker writes that the breakout product for Autodesk was Interact (the precursor to AutoCAD). Initially developed for S-100 bus systems it quickly moved to the PC. There was a lot of demand for CAD at a 5K price point that did not exist at a 50K price point.
> From: Lars Brinkhoff
> It's my understanding it was started by Bob Scheifler of the CLU group.
Yes, that's correct. (Bob's office was right around the corner from me -
although I had very little knowledge of what his group was up to; I was too
busy with other things.)
I have this vague memory that his version was actually written in CLU? Can
that be correct? It would make sense, since that group was so focused on CLU
- but maybe not, see below.
X must have been done after LCS got the 750 farm (on which we ran 4.1c, to
start with) - although I don't know what kind of terminals they were using to
run X on - we didn't have any bit-mapped displays on them, I'm pretty sure.
Although maybe it was later, once Micro-Vaxes appeared?
I have this vague memory that it was based (perhaps only in design, not code
re-use) on a window system done at Stanford {looks}; yes, W (hence 'X'):
https://en.wikipedia.org/wiki/W_Window_System
The X paper listed there:
https://dl.acm.org/doi/pdf/10.1145/22949.24053
doesn't say anything about the implementation, so maybe that vague
memory/assumption that I had that it was originally written in CLU is wrong.
Liskov's 'History of CLU' paper, which lists things done in CLU, doesn't
mention it, so I must have been confused?
Do any of the really early versions of X (and W) still exist?
Noel
Hi.
I've been using trn for decades to read a very few USENET groups. Until recently I've
been using aioe.org as my NNTP server but it seems to have gone dark. Before that
I used eternal-september.org, but when I try that I now get:
| $ NNTPSERVER=news.eternal-september.org trn
| Connecting to news.eternal-september.org...Done.
|
| Invalid (bogus) newsgroup found: comp.sys.3b1
|
| Invalid (bogus) newsgroup found: comp.sources.bugs
|
| Invalid (bogus) newsgroup found: comp.misc
|
| Invalid (bogus) newsgroup found: comp.compilers
| ....
And those all are (or were!) valid groups. If anyone has suggestions for a good
free NNTP server, please let me know. Privately is fine. I'm at a bit of
a loss otherwise.
Thanks,
Arnold
i worked for some years on video and film archive restoration.
baking old, badly stored magnetic tapes prior to reading them is a common practice.
my favourite was a story of a rock band (i think the stones) who wanted to play an old 24 track master tape but discovered it seemed to be stuck together.
there is a nasty affliction of mag tapes called sticky vinegar syndrome, so they did the right thing and sent a section of tape for analysis.
the results came back: the tape had suffered impregnation with “vodka and coke”.
some things never change.
-Steve
Hi All,
I just wanted to let y'all know that tesseract ocr has significantly
improved and is much easier to use that it used to be. I have been using
it with my workflow for a bit and it's crazy how much better it is than
it was back when I tried it last (admittedly 5-6 years ago). For those
of you doing your own scans, or those of you finding sad little pdfs
without ocr, the process is fairly simple.
Let's say you find "The Master Manual of Fortran.pdf" out there in the
wild (or scan it). Here's how to turn it into a glorious ocr'd version:
Export your pdf as a multi-image tiff - it'll be ginormous, but you can
delete it later (on Mac, this is just export from preview and select
tiff, but gs will do it to, if I remember correctly) and then:
tesseract The\ Master\ Manual\ of\ Fortran.tiff out -l eng PDF
et voila, I nice, if large pdf, called out.pdf or somesuch will appear
with ocr text that actually matches your scan (it seems to have caught
up to adobe's ocr, or is quite close in my view, ymmv).
I speak English, so I installed tesseract and tesseract-eng, but it
supports a bunch of other languages if you need them. Apparently
google's been supporting and developing it for while now and if my
results are any indicator, it's paying off (boy do I remember all the
gobbledegook it used to produce).
tesseract will import from different image types, multiple images, etc.
I just like the simplicity of tiff->pdf.
Anyhow, thought y'all might like to know as many of you live off the
scans :).
Will
If you don't want to play Space Travel on PDP-7 Unix, you can now do it
more easily running this C port. The controls are--so far--just as
quirky as the original.
https://github.com/mohd-akram/st
At 01:20 AM 1/26/2023, John Cowan wrote:
>WP says the Terak 8510/a was the first graphical workstation; it came out in 1976-77 and ran the UCSD p-System. I had never heard of it before.
I have a dozen or so Teraks (a PDP-11/03 based system) as well as
many floppies and other inherited items and notebooks from one
of the Terak founders. This may seem like a lot but there's another
guy who might still have a larger collection.
Mini-Unix is described here:
http://www.tavi.co.uk/unixhistory/mini-unix.html
Sixth edition, no MMU. The Bell memo there is dated January 1977.
There was a Mini-Unix for the Terak described here in May 1979 but
I don't think I have a copy. See page 14...
https://conservancy.umn.edu/bitstream/handle/11299/159028/UCC_Special%20_Is…
Terak floppies are described here:
http://www.60bits.net/msu/mycomp/terak/termedia.htm
A memo there says they got their copy in April 1980.
There's no indication that this Mini-Unix can *use* the Terak's mono
bitmapped display, short of writing your own routines. Pinning "first"
on computers is always a tricky process.
- John
>> * What do I really mean by workstation? Ex.gr. If an installation had a
>> PDP-11 with a single terminal and operator, is it not a workstation? Is
>> it the integration of display into the system that differentiates?
>
> I remember people calling something a workstation,
> if it has the four "M"
>
> at least 1 MByte memory
> at least 1 megapixel display
> at least 1 mbit/s network
> can't remember the fourth(was there a fourth?)
I remember it as:
at least 1 MByte memory
at least 1 megapixel display
at least 1 MIPS
cost at most 1 mega penny (10K, maybe 35K in today’s money)
That matches with Wikipedia, for whatever that is worth: https://en.wikipedia.org/wiki/3M_computer
but note that it talks about 3M not 4M.
With hindsight, not adding in networking speed looks strange -- but maybe the world had already settled on LAN speeds above 1Mb/s by 1980 (Ethernet, ARCNet)
[Bcc: to TUHS as it's not strictly Unix related, but relevant to the
pre-history]
This came from USENET, specifically, alt.os.multics. Since it's
unlikely anyone in a position to answer is going to see it there, I'm
reposting here:
From Acceptable Name <metta.crawler(a)gmail.com>:
>Did Bell Labs approach MIT or was it the other way around?
>Did participating in Project MAC come from researchers requesting
>management at Bell Labs/MIT or did management make the
>decision due to dealing with other managers in each of the two
>organizations? Did it grow out of an informal arrangement into
>a format one?"
These are interesting questions. Perhaps Doug may be in the know?
- Dan C.
Good morning all, currently trying to sort out one matter that still bewilders me with this documentation I'm working on scanning.
So I've got two copies of the "Release 5.0" User's Manual and one copy of the "System V" User's Manual. I haven't identified the exact differences, lots of pages...but they certainly are not identical, there are at least a few commands in one and not the other.
Given this, and past discussion, it's obvious Release 5.0 is the internal UNIX version that became System V, but what I'm curious about is if it was ever released publicly as "Release 5.0" before being branded as System V or if the name was System V from the moment the first commercial license was issued.
The reason I wonder this is some inconsistencies in the documentation I see out there. So both of my Release 5.0 User's Manuals have the Bell logo on the front and no mention of the court order to cease using it. Likewise, all but one of the System V related documents I received recently contain a Bell logo on the cover next to Western Electric save for the Opeartor's Guide which curiously doesn't exhibit the front page divestiture message that other documents missing the Bell logo include. Furthermore, the actual cover sheet says "Operator's Guide UNIX System Release 5.0" so technically not System V. In fact, only the User's Manual, Administrator's Manual, Error Message Manual, Transition Aids, and Release Description specifically say System V, all the rest don't have a version listed but some list Release 5.0 on their title page.
Furthering that discrepancy is this which I just purchased: https://www.ebay.com/itm/314135813726?_trkparms=amclksrc%3DITM%26aid%3D1110…
Link lives as of this sending, but contains a closed auction for an Error Message Manual from the "Release 5.0" documentation line but no Bell logo. Until the Operator's Guide and this auction link, I haven't seen any "Release 5.0" branded stuff without a Bell logo, and before I bought the System V gold set, I hadn't seen System V branded stuff *with* the Bell logo.
This shatters an assumption that I had made that at the same time the documentation branding shifted to System V was the same time the removal of the Bell logo happened, given that divestiture was what allowed them to aggressively market System V, but now this presents four distinct sets of System V gold documentation:
Release 5.0 w/ Bell logo
Release 5.0 w/o Bell logo
System V w/ Bell logo
System V w/o Bell logo
I'm curious if anyone would happen to know what the significance here is. The covers are all printed, I can't see any indication that a bunch of 5.0 manuals were retroactively painted over nor that any System V manuals got stamped with a Bell post-production. What this means is "Release 5.0" documentation was being shipped post-divestiture and "System V" was being shipped pre-divestiture. If Release 5.0 was publicly sold as System V, then what explains the post-divestiture 5.0 manuals floating around in the wild, and vice versa, if USG couldn't effectively market and support UNIX until the divestiture, how is it so many "Release 5.0" documents are floating around in well produced commercial-quality binding, both pre and post-divestiture by the time the name "System V" would've been king. Were they still maintaining an internal 5.x branch past System V that warranted its own distinct documentation set even into the commercial period? This period right around '82-'83 is incredibly fascinating and I feel very under-documented.
- Matt G.
Good day everyone, just emailing to notify of three more documents I've uploaded to archive.org since my last slew of them:
https://archive.org/details/unix-programming-starter-package - Up first is the UNIX Programming Starter Package. This is one of a pair of manuals that saw publication in the Bell system around the time of UNIX/TS 4.0. The documents here appear to be a subset of those which shipped with Documents for UNIX 4.0. Nothing particularly new here. There is a companion manual, UNIX Text Editing & Phototypesetting Starter Package, which I also have but haven't hit the scan bench with yet. Like this one, that is just a subset of papers from the Documents for UNIX collection. Based on the TOC, this second one also shipped with one of those PWB/MM multi-fold pamphlets, but didn't receive one when I got this. Luckily that was also scanned as part of the 4.0 collection. So nothing really new here, save that these are 1st generation scans vs the scans of photocopies for the 4.0 release. That said, I've seen this set with the same cover motif except with an AT&T death star logo in the upper right. Didn't look into it too much at the time, but I'd be curious if anyone might have those and if they have the programming one, if it still refers to Release 4.0 in the documentation roadmap.
https://archive.org/details/unix-system-users-guide-release-5-0 - This is the User's Guide that shipped with Release 5.0/System V. This covers the usual suspects as well as some notes on RJE and SCCS from a user's perspective.
https://archive.org/details/unix-system-administrators-guide-5-0 - And this is the Administrator's Guide likewise from SysV era. This one contains setup and maintenance notes for both DEC (PDP & VAX) and 3B20(S) machines, as well as papers on accounting, LP printing, RJE, filesystem checking, and the System Activity Package. Additionally, the guide includes the original Modification Request form.
- Matt G.
Found this tweetstream, here folded together, when looking for something
else (now lost) in my twitter archive:
==========
Things I miss from the v8 shell.
1) All shell output was valid shell input.
2) Typing dir/cmd would find the command $PATH/dir/cmd. Subdirectories of
your bin, in other words.
3) Functions were exportable. For one brief shining POSIX meeting, that was
true in POSIX too but then...
4) The implementation was lovely and easy to understand. (No, it wasn't
shalgol. Bourne fixed that for us.)
5) That I could learn things from it, like how to write a recursive descent
parser.*
6) It ran in cooked mode.
As expected, all that work making it a great shell is lost to history.
https://t.co/IzApAUSmzN is silent. Well, the code is released now.
==========
-rob
* elegantly.
> From: Larry McVoy <lm(a)mcvoy.com>
> At least 30 years ago I said "He's good programmer, a good architect,
> and a good manager. I've never seen that in one person before".
Corby? Although he was just down the hall from me, I never saw him operating
in any of those roles; maybe some of the old-time Unix people have some
insight. Saltzer is about off-scale in #2; probably good as a manager
(although I had a monumental blow-up with him in the hallway on the 5th
floor, but I was pretty close to unmanageable when I was young ;-); he took
over Athena when it was stumbling, and got it going. Dave Clark is high on
all three - he could manage me! :-)
Bob Taylor? PARC did some _incredibly_ important stuff in his time. Yes, I
know a lot of the credit goes to those under him (Butler Lampson, Alan Kay -
not sure if he was in Taylor's group, Boggs, Metcalfe, etc) but he had to
manage them all. Not sure what his technical role was, though.
Vint Cerf? Again, A1*** as a manager, but had some failings as a architect. I
think the biggest share of the blame for the decision to remove the variable
size addresses from TCP/IP3, and replace them with 32-bit addresses in
TCP/IPv4, goes to him. (Alas, I was down the hall, not in the room, that day;
I wasn't allowed in until the _next_ meeting. I like to think that if I'd been
there, I could/would have pointed out the 'obvious' superior alternative -
'only length 4 must be supported at this time'.)
Noel
PS: ISTR that about a month ago someone was asking for management papers
from that era (but I was too busy to reply); two good ones are:
- F. J. Corbat��, C. T. Clingen, "A Managerial View of the Multics System Development"
https://multicians.org/managerial.html
- F. J. Corbat��, C. T. Clingen, and J. H. Saltzer, "Multics -- the first seven years"
https://multicians.org/f7y.html
> My guess is that Ivan Sutherland probably qualified back when he still
> programmed ... I mean, after all, he invented the linked list in order to
> implement his thesis program (Sketchpad) in about 1960.
I don't know whether Sutherland invented the linked list, but if he
did, it had to be before he worked on sketchpad. I attended a lecture
about Lisp in 1959 in which McCarthy credited list-processing to
IPL-V, whose roots Newell places in 1954. Sketchpad ran on TX 0, which
became operational in 1956.
My nomination for a triple-threat computer guy is Vic Vyssotsky. A
great programmer, he invented the first stream-processing language
(BLODI) and bitwise-parallel dataflow analysis. As an architect, he
invented the single underlying address space for multics. As a
manager, he oversaw the building of and later ran the lab that became
AT&T Research. Finally he founded the DEC Cambridge Lab. He was a
subtle diplomat, too, who more than once engineered reversals of
policy without ruffling feathers.
Relative to linked lists, I remember Vic perceptively touting the then
startling usage J=NEXT(J).in Fortran.
Doug
Accidentally sent this only to the person I was replying to.
> I am getting some grief on Twitter too for "omitting" FreeBSD. I
> didn't, but the BSDs don't fit either definition of "Unix". The
> pre-1993 one being "based on AT&T code" -- after all, BSD (4.4 Lite r2
> was it? Before my time!) -- went to a lot of effort to eliminate AT&T
> code.
From what I've seen it's very much a gradual transition; 4.3-Tahoe starts to
have the new code and UCB copyright notices with the predecessor of what we call
the "BSD License" appearing in some of the source files. Then with Reno, a
majority of the userland is open-sourced, and Net/2 is fairly complete. (Net/2
and 4.4BSD-Lite / Lite/2 were lacking a few things.) But even right up until
the end things were in a state of flux.
A few things weren't finished until much later by the FreeBSD, OpenBSD and
NetBSD people.
-uso.
Hello --
Regarding "appliance-ization" (locking down / dumbing down) of commercially-available computer systems, and returning to the history of Unix (in the context of our current era), I am reminded of Ken Thompson's (excellent and humorous) panel presentation at the ACM Turing 100 conference I attended in 2012, imagining Alan Turing being brought to our time and given a current-generation computer system, etc.
The webcast links for the "Systems Architecture" session, etc., on the main conference site, https://turing100.acm.org/, seem to be broken, however the video at this link works for me:
https://dl.acm.org/doi/10.1145/2322176.2322182
(Ken's part starts at ~0:09:28.)
Cheers,
***PSI***
<<<psi(a)valis.com>>>
tuhs-request(a)tuhs.org writes:
[...]
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 18 Jan 2023 17:08:00 +0000
> From: segaloco <segaloco(a)protonmail.com>
> Subject: [TUHS] Re: Maintenance mode on AIX
> To: Clem Cole <clemc(a)ccc.com>
> Cc: tuhs(a)tuhs.org
> Message-ID: <zpdIicuX7AbN-y6hYho0eLOnHgzRs4iHa1UD6bxUyiTZhqZkg3Ha8TKWV
> ASxWkDZitFw0JIopRVh7BRC2PzLFrF_Gjsb2yCi-uxJ3Yr3AtE=(a)protonmail.com>
> Content-Type: multipart/alternative;
> boundary="b1_7WKJsCnT0P2jggZLBLwbL2iRavDFXPykjXdIMPRs"
>
> Apple's unreasonable hardening has been the latest deterent to my ever wanting to use macOS as a personal driver. I've got a Mac as my daily driver for work, it can happily stay with work until I can decide how the filesystem is laid out and what folders I, as the root user, can and can't interact with from user land. I own my machine, not Apple.
>
> - Matt G.
> ------- Original Message -------
> On Wednesday, January 18th, 2023 at 8:59 AM, Clem Cole <clemc(a)ccc.com> wrote:
>
>> On Wed, Jan 18, 2023 at 11:39 AM Larry McVoy <lm(a)mcvoy.com> wrote:
>>
>>> Someone once told me that if they had physical access to a Unix box, they
>>> would get root. That has been true forever and it's even more true today,
>>> pull the root disk, mount it on Linux, drop your ssh keys in there or add
>>> a no password root or setuid a shell, whatever, if you can put your hands
>>> on it, you can get in.
>>
>> A reasonable point, but I think it really depends on the UNIX implementation I suspect. Current mac OS is pretty well hardened from this, with their current enclaves and needing to boot home to Apple to get keys if things are not 100% right. Not saying you or I can not, but basically means the same cracking tricks you need to use for iPhones. It's not as easy as you describe.
>>
>> The ubiquitous Internet/WiFi changed the rules - as you can start to keep some set of keys somewhere else and then encrypt the local volumes. In fact, one of the things they do if mac OS boot detects that root has been modified (it has a crypto index stored away when it was made read-only), the boot rolls back to the last root snapshot -- since they are all read-only that works. In fact, it is a PITA to update/fix things like traditional scripts (for instance the scripts in the /etc/periodic area). Basically, they make it really unnatural to change the root files system, make a new snapshot and index (I have yet to see it documented although, with much pain, I previously created a procedure that is close -- i.e. it once worked on my pre-Ventura Mac - but currently -- fails, so I need to some more investigation when I can bring this back to the top of the importance/curiosity stack (I have a less than satisfying end around for now so I'm ignoring doing it properly).
>>
>> Clem
>> ᐧ
I just stumbled across an old letter, from a VP of Burroughs to me and
Steve Bartels, authorizing $30,000 for a port of Unix to the E-mode stack
machine. I had forgotten getting it.
Burroughs was famed for its stack machines. E-mode was a kind of last gasp
attempt to save the stack architecture, which failed as far as I know, see
this table:
http://jack.hoa.org/hoajaa/Burr126b.html
I worked as a hardware engineer on the A15. I also had been a Unix user for
7 years at that point and kept pointing out how awful the Burroughs CANDE
time-sharing system was, and how much better Unix was. At some point I
guess they asked me to put up or shut up. I got that money, and left
Burroughs a week later for grad school.
Funny note: A15 was Motorola ECL (MECL), and ran at 16 Mhz., considered
fast at that time. We used a technique called "stored logic" which was,
believe it or not, using MECL RAM to map logic inputs to outputs, i.e.
implement combinational logic with SRAM. Kind of nuts, but it worked at the
time. We also used a precursor of JTAG to scan it in. Those of you who know
JTAG have some idea of how fun this had to be.
One side effect of working with MECL is you realized just how well designed
the TI 7400 SSI/MSI parts were ... MECL always just felt like an awkward
family to design with.
Another funny story, pointing to what was about to happen to Burroughs. We
had an app that ran for hours on the stack machine. We quick ported it to a
VAX, started it up, and headed out to lunch -- "this will take a while,
let's go eat." We got to the front door and: "Oh, wait, let me hop back
into the office,I forgot my jacket". And, noticed, the program was done in
... about 3 minutes. Not 8 hours.
That's when we knew it was game over for Burroughs.
If a picture of this letter would be useful in some archive somewhere, let
me know, I can send it.
The security vulnerability in question could be briefly summarized as,
"Fortran divide-by-zero gives root." I think that was just a specific
manifestation of the underlying problem, though. More specifically it
was actually due to failure to sanitize state after handling a SIGFPE
(and possibly other signals as well?).
I have a distinct memory of this, but can no longer find any evidence
for it. Did I just make it up from whole cloth, or was this actually a
thing?
- Dan C.
London and Reiser report about porting the shell that “it required by far the largest conversion effort of any supposedly portable program, for the simple reason that it is not portable.” By the time of SysIII this is greatly improved, but also in porting the SysIII user land it was the most complex of the set so far.
There were three aspects that I found noteworthy:
1. London/Reiser apparently felt strongly about a property of casts. The code argues that casting an l-value should not convert it into a r-value:
<quote from "mode.h">
/* the following nonsense is required
* because casts turn an Lvalue
* into an Rvalue so two cheats
* are necessary, one for each context.
*/
union { int _cheat;};
#define Lcheat(a) ((a)._cheat)
#define Rcheat(a) ((int)(a))
<endquote>
However, Lcheat is only used in two places (in service.c), to set and to clear a flag in a pointer. Interestingly, the 32V code already replaces one of these instances with a regular r-value cast. So far, I’d never thought about this aspect of casts. I stumbled across it, because the Plan 9 compiler did not accept the Lcheat expansion as valid C.
2. On the history of dup2
The shell code includes the following:
<quote from “io.c”>
rename(f1,f2)
REG INT f1, f2;
{
#ifdef RES /* research has different sys calls from TS */
IF f1!=f2
THEN dup(f1|DUPFLG, f2);
close(f1);
IF f2==0 THEN ioset|=1 FI
FI
#else
INT fs;
IF f1!=f2
THEN fs = fcntl(f2,1,0);
close(f2);
fcntl(f1,0,f2);
close(f1);
IF fs==1 THEN fcntl(f2,2,1) FI
IF f2==0 THEN ioset|=1 FI
FI
#endif
}
<endquote>
I’ve check the 8th edition source, and indeed it supports using DUPFLG to signal to dup() that it really is dup2(). I had earlier wondered why dup2() did not appear in research until 10th edition, but now that is clear. It would seem that the dup of 8th edition is a direct ancestor to dup() in Plan 9. I wonder why this way of doing things never caught on in the other Unices.
3. Halfway to demand paging
I stumbled across this one because I had a bug in my signal handling. From early days onwards, Unix supported dynamically growing the stack allocation, which arguably is a first step towards building the mechanisms for demand paging. It appears that the Bourne shell made another step, catching page faults and expanding the data/bss allocation dynamically:
<quote from “fault.c”>
VOID fault(sig)
REG INT sig;
{
signal(sig, fault);
IF sig==MEMF
THEN IF setbrk(brkincr) == -1
THEN error(nospace);
FI
ELIF ...
<endquote>
This was already present in 7th edition, so it is by no means new in 32V or SysIII -- it had just escaped my attention as a conceptual step in the development of Unix memory handling.
Here’s a stretch, but does anybody have a copy of the 1982-ish C With
Classes Reference Manual kicking around. I can take it in n/troff or a
more modern format if you have it.
> segaloco via TUHS writes:
>> I think that's a good point that scripting problems may be
>> a symptom of the nature of the tools being used in them.
> I think that you're hinting at something different.
> To the best of my recollection, scripting languages were originally
> intended and used for the automation of repetitive personal tasks;
> making it easier for users who found themselves typing the same
> stuff over and over again.
Indeed!
> Somewhere along the line people forgot
> how to use a compiler and began writing large systems in a variety
> of roughly equivalent but incompatible interpreted languages. Can
> one even boot linux without having several different incompatible
> versions of Python installed today? So I don't think that it's the
> nature of the tools; I think that it's people choosing the wrong
> tools for the problems that they're trying to solve.
> Jon
The forgotten compilers were typically used to supply glue
to paste major tools together. The nature of that glue---often
simple data reformatting--inspired tools like sed and awk.
Each use of a tool became a process that saved many minutes
of work that would in a scriptless world be guided by hand,
boringly and unreliably.
Yet glue processes typically did only microseconds of
"real" work. In the name of efficiency, the operations began
to be incorporated directly into the shell. The first
inklings of this can be seen in "echo" and various forms
of variable-substitution making their way into the v7
shell. The phenomenon proliferated into putting what were
typically canned sed one-liners (but not sed itself) into
the shell.
Lots of specializations crowded out universality. A side
effect was an explosion of knowledge required to write
or understand code. Such is the tragedy of "forgetting
compilers".
Doug