> 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...…
[View More] 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
[View Less]
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 …
[View More]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
[View Less]
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 …
[View More]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
[View Less]
> 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]);
…
[View More] 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
[View Less]
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 …
[View More]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/ -
-------------------------------------------------------------------------------
[View Less]
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
> From: "Jeremy C. Reed" <reed(a)reedmedia.net>
> Later, they considered an LNI, an early token ring (if I understand
> correctly), device
Yes. See:
http://ana-3.lcs.mit.edu/~jnc/history/RingMIT.txt
for more - that's a pre-print version of an article just published in the
_IEEE Annals of the History of Computing_; slight differences with the final
version, but nothing significant.
Thumbnail: There were two versions; V1 was 1MBit/second, produced in very
limited …
[View More]numbers (~10 or so) at MIT, most used there, although IIRC correctly
at pair (at least - one would be of no use :-) went to UCLA (I remember flying
out to LA to help them get them going). V2 was 10Mbit/second, produced as a
commercial product by Proteon in cooperation with MIT, large numbers sold.
Noel
[View Less]
The 3b1 emulator now kind of boot!..
There is some issues with stuff, but for the most part, it works
http://virtuallyfun.superglobalmegacorp.com/?p=4149
-----Original Message-----
From: arnold(a)skeeve.com [mailto:arnold@skeeve.com]
Sent: Tuesday, August 26, 2014 2:17 PM
To: lyndon(a)orthanc.ca; lm(a)mcvoy.com
Cc: rob(a)bolabs.com; tuhs(a)minnie.tuhs.org
Subject: Re: [TUHS] networking on unix before uucp
Larry McVoy <lm(a)mcvoy.com> wrote:
> On Mon, Aug 25, 2014 at 01:00:45PM -…
[View More]0700, Lyndon Nerenberg wrote:
> > It was quite astounding to see the wide range of performance impacts
> > this had on various systems. 3B* systems would tip over and die, except
> > for the (built by Convergent Tech) 3B1.
>
> Sheesh, you people keep bringing up stuff from my past. My buddy Rob
> Netzer (used to be a prof at Brown, now works on BitKeeper with me)
> had one of those 3B1s. Neat machine. Sort of like a desktop VAX.
I had one too. (Also a trailblazer and then a worldblazer.) The 3B1 ran
SVR2; the BSD networking was available as an add-on with the ethernet
card.
I spent many happy hours working on that box, developing gawk and its
documentation; it was slow enough that you could see algorithmic
differences, e.g. standard diff vs. GNU diff.
It had one of those great AT&T keyboards (as did the blit). The UI
wasn't anything special to write home about though.
For a while there was a separate 3b1.* set of newsgroups and an
archive of stuff at Ohio State; there remains a comp.sys.3b1 group
that still has some activity as new people try to revive some of
these machines and others who had them help out. Someone was writing
an emulator, but I don't think it ever got finished.
Ah, the memories .... :-)
Arnold
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
[View Less]
