At 07:46 PM 9/8/2014, you wrote:
>Traffic this evening on the pcc compiler list <pcc.lists.ludd.ltu.se>
>alerted me to the existence of the Software Preservation Group, a
>branch of the Computer History Museum, with a Web site at
>
> http://www.softwarepreservation.org/
Also at http://www.computerhistory.org/groups/spg/ .
It's run by Al Kossow:
http://www.computerhistory.org/staff/Al,Kossow/
He worked at Apple for a long time. His early years were at UW-Milwaukee.
He also frequents the Classic Computer Collector mailing list, a place
where you might acquire and learn to repair the old iron.
- John
The recent UUCP network conversation has me wondering ... is anyone collecting/curating the UUCP maps that represented the way we communicated (outside the ARPANET) from the time of Chesson's paper until the death of comp.mail.maps? Brian Reid's postscript maps were a work of genius; the hand-drawn ASCII maps that predated those are even more wonderful bits of Internet history, let alone art.
--lyndon
> Speaking of using a pipe to an existing command, I originally mis-read the
> code to think there was only _one_ process involved, and that it was buffering
> its output into the pipe before doing the exec() itself - something like this:
>
> pipe(p);
> write_stuff(p[1]);
> close(0);
> dup(p[0]);
> close(p[0]);
> close(p[1]);
> execl("/bin/other", "other", arg, 0);
>
> Which is kind of a hack, but... it does avoid using a second process, although
> the amount of data that can be passed is limited. (IIRC, a pipe will hold at
> most 8 blocks, at least on V6.) Did this hack ever get used in anything?
I didn't notice anybody commenting on the fact that this hack doesn't
work for the purpose--an interactive desk calculator. Running bc then
dc serially defeats interactivity.
The scheme of filling a pipe completely before emptying it is used
in Rob Pike's plan9 editor, sam, to pipe text through some transforming
process. Because the transformer (think sort) may not produce any
output until it has read all its input, sam can't read the result
back until it has finished stuffing the pipe.
Of course sam has to create two pipes, not just one, and it happens
that the initial writer and ultimate reader are the same. But the
basic idea is the same.
Doug
Speaking of things etymological, I've heard two versions of that for
dsw(1).
Delete from Switch Register (delete file whose i-num is in CSR)
Delete Sh*t Work (same, but expressed a bit more robustly)
-- Dave
> From: Dave Horsfall <dave(a)horsfall.org>
> On the *nix systems to which I have access, bc(1) is a standalone
> program on FreeBSD and OSX, but pipes to dc(1) on OpenBSD. I cannot
> check my Penguin box (Ubuntu)
Dude! Trying to answer questions about the origins of BC by looking at
systems this late is like trying to learn Latin by studying Italian! :-)
I looked at the Version 6 source, and it's a bunch of YACC code, but it pulls
the same technique of using a pipe to an instance of DC, viz:
pipe(p);
if (fork()==0) {
close(1);
dup(p[1]);
close(p[0]);
close(p[1]);
yyinit(argc, argv);
yyparse();
exit();
}
close(0);
dup(p[0]);
close(p[0]);
close(p[1]);
execl("/bin/dc", "dc", "-", 0);
There's likely even older versions than the V6 one, but that's the earliest
source I have online on my PC for easy access.
Noel
Hello,
on de.comp.os.unix.shell there is a recent thread about bc(1) which
turned into a discussion about why it is called "bc". dc(1) is pretty
clearly "desk calculator" as by the man page, but the etymology of bc
seems to be unclear.
I've heard the following plausible theories:
- basic calculator (Wikipedia)
- beauty calculator (some people apparently dislike RPN)
- better calculator
- bench calculator (Wikipedia)
- b is the letter d mirrored (RPN vs algebraic)
- bundle calculator (the word "bundle" appears 97 times in bc.y of V6)
...but nobody had a really conclusive argument. Perhaps someone here
remembers the real story?
Thanks,
--
Christian Neukirchen <chneukirchen(a)gmail.com> http://chneukirchen.org
> From: Mark Longridge <cubexyz(a)gmail.com>
> I have a version of Unix v6 that has a file called /usr/doc/bc that
> describes bc at length
Oh, right, I missed that. I'm a source kind of person... :-)
Speaking of using a pipe to an existing command, I originally mis-read the
code to think there was only _one_ process involved, and that it was buffering
its output into the pipe before doing the exec() itself - something like this:
pipe(p);
write_stuff(p[1]);
close(0);
dup(p[0]);
close(p[0]);
close(p[1]);
execl("/bin/other", "other", arg, 0);
Which is kind of a hack, but... it does avoid using a second process, although
the amount of data that can be passed is limited. (IIRC, a pipe will hold at
most 8 blocks, at least on V6.) Did this hack ever get used in anything?
Noel
Traffic this evening on the pcc compiler list <pcc.lists.ludd.ltu.se>
alerted me to the existence of the Software Preservation Group, a
branch of the Computer History Museum, with a Web site at
http://www.softwarepreservation.org/
I do not recall hearing of it before today, and perhaps a few TUHS
list readers have not either. It may be desirable to add a link to it
from the Unix block of the http://minnie.tuhs.org/ site.
I think that it could also be good to record a link to the Bitsaver's
site at
http://bitsavers.trailing-edge.com/
and to make a list of TUHS mirrors more prominent (e.g., we have one
at
http://www.math.utah.edu/mirrors/minnie.tuhs.org/
).
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
Hi folks,
I was wondering if Unix had any form of networking before uucp
appeared in Unix v7. It would be interesting to know if one could pass
a file from one Unix v5 machine to another without having to store it
on a magnetic tape.
There's some reference to a mysterious "Spider Interface" in the Unix
v5 manual. It seems to have something to do with DR-11B (which is a
general purpose direct memory access interface to the PDP-11 Unibus).
There's also reference to the "Spider line-printer" :)
Mark
