
Bourne Basic – a BASIC interpreter implemented in pure Bourne shell (1987) - networked
https://gist.github.com/cander/2785819
======
echochar
When I read "pure Bourne shell" I expected just /bin/sh.

This uses cat, sed, rm, cp, grep, bc, sort, etc. too.

The shell part may be "pure Bourne shell" but there are other utilities
involved besides sh.

I guess it was not the convention in 1987 and probably not today either but if
it were me I would mention those other utilities.

As a challenge, I always try to minimize the number of extra utilities I have
to use, and then I try to stick with the most common, basic ones.

As a result I get highly portable scripts that run just about anywhere, even
in reduced functionality, embedded environments, especially non-Busybox ones.

In my experience, cp and rm are to be expected in any userland.

cat and sed are another two of the most common, basic utilities.

But things like grep -v... I would only use that if there were no other way to
do the task; e.g., can we accomplish task with sed /pattern/d\;...?

If you're willing to include AWK you can do just about anything; personally I
do not rely on AWK being present everywhere.

~~~
cturner
I like thinking about this problem space. However, I do rely on awk. Awk has
been around since V7, I've not yet found a system without it.

A gap I've spent some time thinking about in constrained unix - how to do
socket IPC. For example - building a cgi server. So far I've struggled without
either a modern scripting language (perl, python, etc) or else a C compiler.
And locked-down or decrepit systems will often lack a working C compiler.

I'd expect someone who knew what they were doing could build an awk tool that
would parse a DSL to produce binaries that makes unix system calls. Probably
awkward, you'd need to do your own elf packaging. A problem I might one day
get around to.

~~~
echochar
Thanks for commenting.

I experimented with small C compilers but UNIX is too intertwined with too
many "standard" C libraries. I would like to see a UNIX that used some other
libraries, if for nothing else as a proof of concept; e.g., maybe use some of
djb's libraries. musl is a good start.

Eventually I decided to just include "as" in the userlands in my small systems
instead. I have a library of small asm routines that I keep available, similar
to C's "standard" libraries but not taking up the enormous space they do.

But I think the easy way to do socket IPC is just include socat or some other
alternative like tcpserver or a small httpd.

Statically compiling socat is made easy and I really admire how the author
makes it possible to add/subtract features when compiling. It's the antithesis
of forcing the user to accept the kitchen sink, which alas is the norm. Smart.

If the systems you are targeting have a RAM based filesystem that you can
mount and transfer files to, and enough RAM to spare, you should be able to
run a static binary from RAM that can listen on a socket and run
scripts/programs.

------
PhasmaFelis
It's charming to remember that there was an era when you could document half
your commands with "works as expected."

