From: Dave Plonka <email@example.com>
Subject: [TUHS] capturing history of bs(1) command / programming language
Date: Mon, 30 Sep 2019 14:29:55 -0500 [thread overview]
Message-ID: <CANPwAQapt6dWw-yYdMne7wtxt8Q1=nAoBrc9Ca3xgwnBwrZBrg@mail.gmail.com> (raw)
Hi TUHS folks,
Earlier this month I did a fair bit of research on a little known Unix
programming language - bs - and updated the wikipedia pages
Thanks for solving some bs mysteries goes to its author, Dick Haight,
as well as those that got us in touch: Doug McIlroy, Brian Kernighan,
and John Mashey.
Apart from what is in the aforementioned wikipedia page, in exchanging
email with me, Dick shared:
I wrote bs at the time Unix (V 3?) and all of the commands were being
converted from assembler to C. So Thompson’s bas became my bs — sort
of. I included snobol’s succeed/fail feature (? Operator/fail return).
No one asked me to write bs. [...] I tried to get Dennis Ritche to add
something like “? / fail” to C but he didn’t. This is probably part of
why I wrote bs. I wasn’t part of the Unix inner circle (BTL Computing
Research, e.g., Thompson, Ritchie, McIlroy, etc). Neither were Mashey
& Dolotta. We were “support”.
The Release 3.0 manual (1980) mentions bs prominently on page 9:
Writing a program. To enter the text of a source program into a
UNIX file, use ed(1). The four principal languages available under
UNIX are C (see cc(1)), Fortran (see f77(1)), bs (a
compiler/interpreter in the spirit of Basic, see bs(1)), and assembly
language (see as(1)).
Personally, some reasons I find bs noteworthy is (a) it is not much
like BASIC (from today's perspective) and (b) as mentioned in the
wikipedia page, "The bs language is a hybrid interpreter and compiler
and [an early] divergence in Unix programming" (from Research Unix
mentioning only the other three languages):
The bs language was meant for convenient development and debugging of
small, modular programs. It has a collection of syntax and features
from prior, popular languages but it is internally compiled, unlike a
Shell script. As such, in purpose, design, and function, bs is a
largely unknown, modest predecessor of hybrid interpreted/compiled
languages such as Perl and Python.
It survives today in some System III-derived or System V-derived
commercial operating systems, including HP-UX and AIX.
If you have additional information that might be useful for the
wikipedia page, please do share it.
P.S. Here is a 2008 TUHS list discussion, "Re: /usr/bin/bs on HPUX?":
On Wed, Dec 10, 2008 at 01:08:26PM -0500, John Cowan wrote:
> Lord Doomicus scripsit:
> > I was poking around an HP UX system at work today, and noticed a
> > command I've never noticed before ... /usr/bin/bs.
> > I'm sure it's been there for a long time, even though I've been an
> > HPUX admin for more than a decade, sometimes I'm just blind ... but
> > anyway ....
> > I tried to search on google ... it looks like only HPUX, AIX, and
> > Maybe AU/X has it. Seems to be some kind of pseudo BASIC like
> > interpreter.
> That's just what it is. Here are the things I now know about it.
> 0. The string "bs" gets an awful lot of false Google hits, no matter
> how hard you try.
> 1. "bs" was written at AT&T, probably at the Labs, at some time between
> the release of 32V and System III. It was part of both System III and
> at least some System V releases.
> 2. It was probably meant as a replacement for "bas", which was a more
> conventional GW-Basic-style interpreter written in PDP-11 assembly
> language. (32V still had the PDP-11 source, which of course didn't work.)
> 3. At one time System III source code was available on the net,
> including bs.c and bs.1, but apparently it no longer is. I downloaded
> it then but don't have it any more.
> 4. I was able to compile it under several Unixes, but it wouldn't run:
> I think there must have been some kind of dependency on memory layout,
> but never found out exactly what.
> 5. I remember from the man page that it had regular expressions, and
> two commands "compile" and "execute" that switched modes to storing
> expressions and executing them on the spot, respectively. That eliminated
> the need for line numbers.
> 6. It was apparently never part of Solaris.
> 7. It was never part of any BSD release, on which "bs" was the battleships
> 8. I can't find the man page on line anywhere either.
> 9. The man page said it had some Snobol features. I think that meant
> the ability to return failure -- I vaguely remember an "freturn" command.
> 10. 99 Bottles of Beer has a sample bs program at
> http://www2.99-bottles-of-beer.net/language-bs-103.html .
> 11. If someone sends me a man page, I'll consider reimplementing it as
> Open Source.
> We are lost, lost. No name, no business, no Precious, nothing. Only empty.
> Only hungry: yes, we are hungry. A few little fishes, nassty bony little
> fishes, for a poor creature, and they say death. So wise they are; so just,
> so very just. --Gollum cowan at ccil.org http://ccil.org/~cowan
prev parent reply other threads:[~2019-09-30 19:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-10 0:30 [TUHS] /usr/bin/bs on HPUX? Lord Doomicus
2008-12-10 9:45 ` Tim Bradshaw
2008-12-10 14:29 ` Jason Stevens
2008-12-10 18:08 ` John Cowan
2009-01-09 10:51 ` Andrzej Popielewicz
[not found] ` <20190909001945.GA2815@akamai.com>
2019-09-30 19:29 ` Dave Plonka [this message]
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).