[TUHS] Etymology of bc(1)

[TUHS] Etymology of bc(1)

[Noel Chiappa]

    > From: Mark Longridge <cubexyz at 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

[TUHS] Etymology of bc(1)

[Larry McVoy]

On Thu, Sep 11, 2014 at 11:15:55PM -0400, Noel Chiappa wrote:
>     > From: Mark Longridge <cubexyz at 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?

Rob (different rob) and I made a command line expr like thing, can't
remember why that did the same trick of shoving stuff (in our case it
was argv) into a pipe and then running yyparse().

It's at www.mcvoy.com/lm/af.shar

Still builds though it is from 1988.
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] Etymology of bc(1)

[Dave Horsfall]

On Thu, 11 Sep 2014, Noel Chiappa wrote:

> 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?

speaking of pipes, wasn't it PWB that imlemented a write of zero bytes to 
mean end of file, or am I thinking of some other version?  For some 
reason, the Harvard shell and friends, including the TTY driver, come to 
mind.

-- Dave

[TUHS] Etymology of bc(1)

[Noel Chiappa]

    > From: Dave Horsfall <dave at 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

[TUHS] Etymology of bc(1)

[Mark Longridge]

> 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.

There's nothing in the Unix v5 manual about bc and there's no code for
it either. If there's an older version I can't find it.

I have a version of Unix v6 that has a file called /usr/doc/bc that
describes bc at length and it mentions both Lorinda Cherry and Robert
Morris.

There's even a file called /usr/doc/bca which is titled "Appendix"
with even more info.

Bob's Calculator seems plausible enough.

Mark

On 9/11/14, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>     > From: Dave Horsfall <dave at 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
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>

[TUHS] Etymology of bc(1)

[Dave Horsfall]

On Thu, 11 Sep 2014, Noel Chiappa wrote:

> 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! :-)

Perhaps so, but I was a bit surprised that FreeBSD (and I include the Mac
in that) totally rewrote it from a Posix draft, and dropped the pipe.

I no longer have my old manuals (they disappeared during a house move).

-- Dave

[TUHS] Etymology of bc(1)

[John Cowan]

Dave Horsfall scripsit:

> Perhaps so, but I was a bit surprised that FreeBSD (and I include the Mac
> in that) totally rewrote it from a Posix draft, and dropped the pipe.

So did GNU.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Do I contradict myself?
Very well then, I contradict myself.
I am large, I contain multitudes.
        --Walt Whitman, Leaves of Grass

[TUHS] Etymology of bc(1)

[Otto Moerbeek]

On Fri, Sep 12, 2014 at 07:15:12AM -0400, John Cowan wrote:

> Dave Horsfall scripsit:
> 
> > Perhaps so, but I was a bit surprised that FreeBSD (and I include the Mac
> > in that) totally rewrote it from a Posix draft, and dropped the pipe.
> 
> So did GNU.

FreeBSD head has OpenBSD's dc(1) and bc(1) , which does pipe to dc(1).

(I wrote both).

	-Otto

[TUHS] Etymology of bc(1)

[scj]

A gentle reminder that in that era, 4K words of memory cost in the 5
digits of $'s, and many Unix machines had far less than the 64K bytes
(yes, K) that was the maximum.  And there was no paging.  Piping was kind
of a poor man's paging to write programs that would work on small-memory
machines.

While there were benefits, it was also a big pain, especially when
debugging.  And for the most part, we abandoned this style when we got
32-bit machines that had as much as a (gasp!) megabyte of memory...

Steve



>> Dave Horsfall scripsit:
>>
>> > Perhaps so, but I was a bit surprised that FreeBSD (and I include the
>> Mac
>> > in that) totally rewrote it from a Posix draft, and dropped the pipe.
>>
>> So did GNU.

[TUHS] Etymology of bc(1)

[Warner Losh]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1225 bytes --]


On Sep 12, 2014, at 11:12 AM, scj at yaccman.com wrote:

> A gentle reminder that in that era, 4K words of memory cost in the 5
> digits of $'s, and many Unix machines had far less than the 64K bytes
> (yes, K) that was the maximum.  And there was no paging.  Piping was kind
> of a poor man's paging to write programs that would work on small-memory
> machines.
> 
> While there were benefits, it was also a big pain, especially when
> debugging.  And for the most part, we abandoned this style when we got
> 32-bit machines that had as much as a (gasp!) megabyte of memory...

Sure beat the heck out of trying to get overlays right. I remember “fondly”
trying to get the overlay layout manager working to get the FORTRAN programs
I was writing at the time to fit into 64k (or was it 48k). Switching from the PDP-11
to the VAX was a godsend and all that moved into the kernel and got way simpler
from the user perspective…

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140912/10029b12/attachment.sig>

[TUHS] Etymology of bc(1)

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2474 bytes --]

​Steve good point but ...​


On Fri, Sep 12, 2014 at 1:12 PM, <scj at yaccman.com> wrote:

> And for the most part, we abandoned this style when we got
> 32-bit machines that had as much as a (gasp!) megabyte of memory...
>



​Yes and no (know maybe) - as Pike said "cat -v" considered harmful.
The original small is beautiful idea that ​made UNIX so welcome, was lost
in the process.

I remember when we got the money to maxed out the memory on an 11/34 form
48K to 256K bytes (using aftermarket memory of course).  And as you point
it, it is a lot easier when we use the computer to so a lot more of the
work  (that why we have compilers, debuggers and tools in general).   But
when I look at programs written by daugther and her peers, I realized that
just have the innate feel for what is needed to get the job done often
seems lost to them.  Things just grow and use this framework or thank
subsystem.  It so easy to grab, that I wonder if we are ahead or behind.

That said, I do not yearn longly for V6.  It was a fun system and we did a
lot with it and I certainly learned a ton.  But I am way more productive on
my Mac.   But I think the program style and lessons that many of us have
from the those times is to try to get to the nut of the task at hand and
remember how you are getting there.

Let me be less abstract.  I recently found an Open Source NIXIE tube
subsystem from a guy that used an Arduino.   Its very cool and impressive.
 Think about it, use a $4 computer to run each NIXIE tube, instead of lots
of logic to multiples the pins.  But when I looked at his code, I shook my
head.  Basically straight lined everything, brute force.   I remember being
taught, if the routine is longer than a printer page or two, break it up.
I took his code, put a bunch of the things into tables, made a few
functions to use those tables and cut the size of the code even with the
tables, by almost a 3rd and its a lot easier to understand.

In fact, I wrote a small subsystem so I could debug the whole thing using a
UNIX pipe to represent each digit, as debugging on the Arduino is a really,
really poor.

But what did I do - I applied lessons from a great system, UNIX to create a
clean, easy to understand (and even debug).

Anyway - my thesis is that bigger is not always better.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140912/9e0325fe/attachment.html>

[TUHS] Etymology of bc(1)

[Dave Horsfall]

On Fri, 12 Sep 2014, Otto Moerbeek wrote:

> FreeBSD head has OpenBSD's dc(1) and bc(1) , which does pipe to dc(1).

Interesting; FreeBSD seems to be adopting a lot of OpenBSD stuff now, such 
as the PF firewall etc.

> (I wrote both).

Well done, sir!  It's always nice to meet a developer.

-- Dave

[TUHS] Etymology of bc(1)

[Warner Losh]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 734 bytes --]


On Sep 12, 2014, at 1:36 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Fri, 12 Sep 2014, Otto Moerbeek wrote:
> 
>> FreeBSD head has OpenBSD's dc(1) and bc(1) , which does pipe to dc(1).
> 
> Interesting; FreeBSD seems to be adopting a lot of OpenBSD stuff now, such 
> as the PF firewall etc.

There’s a lot of flow between the BSDs these days. Much more than in the Bad Old Days which spawned the 4 different distributions…

Warner


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140912/2fde8946/attachment.sig>

[TUHS] Etymology of bc(1)

[Dave Horsfall]

On Fri, 12 Sep 2014, John Cowan wrote:

> > Perhaps so, but I was a bit surprised that FreeBSD (and I include the 
> > Mac in that) totally rewrote it from a Posix draft, and dropped the 
> > pipe.
> 
> So did GNU.

Which I'd pointed out in a later message (I think).

-- Dave

[TUHS] Etymology of bc(1)

[Tim Bradshaw]

On 12 Sep 2014, at 02:54, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:

> 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'm not a latin scholar, so this is second-hand information.]

Curiously, I understand that studying Italian (or romance languages in general) turns out to be a fairly good way of learning about the Latin, where by "Latin" they mean the language people actually *spoke*, as opposed to the deformed version of it that some tiny minority of people wrote.

In a thousand years, it will also turn out that the best way to learn about Unix will be by reading the archives of some mailing list where people discussed their memories of the early versions of it.

--tim

[TUHS] Etymology of bc(1)

[Dave Horsfall]

On Fri, 12 Sep 2014, Tim Bradshaw wrote:

> Curiously, I understand that studying Italian (or romance languages in 
> general) turns out to be a fairly good way of learning about the Latin, 
> where by "Latin" they mean the language people actually *spoke*, as 
> opposed to the deformed version of it that some tiny minority of people 
> wrote.

And as we stray even further from our original brief (Monty Python quote, 
but OT stuff can be fun at times), English in turn is not Romance but 
Germanic, and has been described as not so much as borrowing words from 
other languages as chasing them down dark alleys and beating them 
senseless.

> In a thousand years, it will also turn out that the best way to learn 
> about Unix will be by reading the archives of some mailing list where 
> people discussed their memories of the early versions of it.

Reckon they might also wonder why Americans don't use English? :-)

In the meantime, the next time NASA launches a probe then perhaps it could 
carry a DVD of Warren's archives; there's both an LP and a CD out there, 
after all.

-- Dave, who would also spell creat(2) with an "e"

[TUHS] Etymology of bc(1)

[Christian Neukirchen]

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 at gmail.com>  http://chneukirchen.org

[TUHS] Etymology of bc(1)

[Warner Losh]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]


On Sep 11, 2014, at 3:24 PM, Christian Neukirchen <chneukirchen at gmail.com> wrote:

> 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?

I’d always heard ‘binary calculator’ but I don’t have a good reference for that.

Warner


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140911/655725cb/attachment.sig>

[TUHS] Etymology of bc(1)

[Dave Horsfall]

On Thu, 11 Sep 2014, Warner Losh wrote:

> I?d always heard ?binary calculator? but I don?t have a good reference 
> for that.

I've heard "binary" because it used binary arithmetic (and limited 
precision), and "basic" because it was a lot simpler than "dc" (which I've 
always thought was "decimal" calculator due to it using arbitrary 
precision decimal arithmetic).

-- Dave

[TUHS] Etymology of bc(1)

[John Cowan]

Dave Horsfall scripsit:

> > I?d always heard ?binary calculator? but I don?t have a good reference 
> > for that.
> 
> I've heard "binary" because it used binary arithmetic (and limited 
> precision), and "basic" because it was a lot simpler than "dc" (which I've 
> always thought was "decimal" calculator due to it using arbitrary 
> precision decimal arithmetic).

That can't be right.  Bc was just an overlay to dc that parsed bc
language, compiled it into dc language, and fed dc from a pipe (all the
output was direct from dc).  So the arithmetic capabilities were exactly
the same.

I note that bc first appeared just about when bas(1) disappeared, so
perhaps there is a connection in their names.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
In the sciences, we are now uniquely privileged to sit side by side
with the giants on whose shoulders we stand.  --Gerald Holton

[TUHS] Etymology of bc(1)

[scj]

Well, Doug McIlroy would probably know definitively, but my memory is that
it was called "bc" because it was written by Bob Morris (senior)--thus,
Bob's calculator.

Steve

[TUHS] Etymology of bc(1)

[Dave Horsfall]

On Thu, 11 Sep 2014, John Cowan wrote:

> > I've heard "binary" because it used binary arithmetic (and limited 
> > precision), and "basic" because it was a lot simpler than "dc" (which 
> > I've always thought was "decimal" calculator due to it using arbitrary 
> > precision decimal arithmetic).
> 
> That can't be right.  Bc was just an overlay to dc that parsed bc 
> language, compiled it into dc language, and fed dc from a pipe (all the 
> output was direct from dc).  So the arithmetic capabilities were exactly 
> the same.

Hey, I never made any claim as to its veracity, and I lost my old manuals 
in a house move.

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) because its keyboard died, and I didn't
set up remote access to it.

All boxen say "arbitrary-precision arithmetic language and calculator" or 
variants thereof.

-- Dave

[TUHS] Etymology of bc(1)

[random832]

On Thu, Sep 11, 2014, at 21:03, Dave Horsfall wrote:
> 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.

What language does the undocumented option (assuming it is supported at
all) "bc -c" generate on FreeBSD and OSX? "Standard" bc, which actually
pipes to dc, generates (obviously) dc when run in this way, but GNU bc
generates a completely different and as far as I know undocumented
language, which is handled by the execute function (in execute.c) but as
far as I know there is no way to make it accept it on standard input.

Standard bc:
$ echo '2+2' | bc -c
 2 2+ps.
q$

GNU bc:
$ echo '2+2' | bc -c
@iK2:K2:+W at r
@i
$


(the @i and @r pseudo-instructions are printed separately from the
generated code when in -c mode [util.c], and are not part of the
language passed to the execute function.)

[TUHS] Etymology of bc(1)

[Steve Nickolas]

On Fri, 12 Sep 2014, random832 at fastmail.us wrote:

> What language does the undocumented option (assuming it is supported at
> all) "bc -c" generate on FreeBSD and OSX? "Standard" bc, which actually
> pipes to dc, generates (obviously) dc when run in this way, but GNU bc
> generates a completely different and as far as I know undocumented
> language, which is handled by the execute function (in execute.c) but as
> far as I know there is no way to make it accept it on standard input.
>
> Standard bc:
> $ echo '2+2' | bc -c
> 2 2+ps.
> q$
>
> GNU bc:
> $ echo '2+2' | bc -c
> @iK2:K2:+W at r
> @i
> $

FreeBSD 10:

$ echo '2+2'|bc -c
  2 2+ps.
q$

(yeah, I run ash... I got a chroot with Debian and the different userlands 
would cause conflict if I defaulted to bash)

-uso.

[TUHS] Etymology of bc(1)

[Dave Horsfall]

On Fri, 12 Sep 2014, random832 at fastmail.us wrote:

> What language does the undocumented option (assuming it is supported at 
> all) "bc -c" generate on FreeBSD and OSX? "Standard" bc, which actually 
> pipes to dc, generates (obviously) dc when run in this way, but GNU bc 
> generates a completely different and as far as I know undocumented 
> language, which is handled by the execute function (in execute.c) but as 
> far as I know there is no way to make it accept it on standard input.

According to my trusty Mac:

DIFFERENCES
    This version of bc was implemented from the POSIX P1003.2/D11 draft and
    contains several differences and extensions relative to the  draft  and
    traditional  implementations.  It is not implemented in the traditional
    way using dc(1).  This version is a single  process  which  parses  and
    runs  a  byte  code  translation  of the program.  There is an "undocu-
    mented" option (-c) that causes the program to output the byte code  to
    the  standard  output  instead  of  running it.  It was mainly used for
    debugging the parser and preparing the math library.

My trusty FreeBSD box says the same thing.  Well, they're both Gnu 1.06, 
after all, and it's some sort of byte-code.  I can sort see how it works; 
single digit integers, unless wrapped by "Knnn:" etc..

> Standard bc:
> $ echo '2+2' | bc -c
>  2 2+ps.
> q$
> 
> GNU bc:
> $ echo '2+2' | bc -c
> @iK2:K2:+W at r
> @i
> $

Oops; a "1" stands for itself, but other ints are bracketed:

davehorsmacbook:~ dave$ bc -c
@ibc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'. 
1+1
11+W at r
@i2+2
K2:K2:+W at r
@i

Amusing that it treats "1" and "not 1" differently.  Oh, and "0" stands 
for itself.  One more test:

00+W at r
@i-1+1
1n1+W at r

So, that's something like "1 negate 1 add" - gasp, that's RPN!  I'd check 
the sources if I had them (none for Mac, and I didn't bother with FBSD).

-- Dave