|
|
|
|
|
|
by cturner
3821 days ago
|
|
|
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. |
|
|
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.