Bourne Basic – a BASIC interpreter implemented in pure Bourne shell (1987) | Hacker News Reader

Bourne Basic – a BASIC interpreter implemented in pure Bourne shell (1987)

gist.github.com

18 pointsnetworked5 comments

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.

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.

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.

This is traditionally what inetd does --- it received incoming connections via sockets and the proxies them to stdin/stdout.

Here's a basic HTTP server in shell:

https://gist.github.com/robspassky/1959319

Of course, it's not as cool as doing the actual low level socket stuff in shell...

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

Reply on news.ycombinator.com