4/1/2026 at 8:41:49 AM
Single standalone file, no external tools used, PATH='' (empty), portable (bash, dash, ksh, zsh), produces x86 ELF executables, has mini-libc builtin.Usage:
printf 'int main(){puts("hello");return 0;}' | sh c89cc.sh > hello
chmod +x hello
./hello
by gaigalas
4/3/2026 at 2:07:26 AM
I can't think of a reason to use c89cc.sh, but I salute this effort nonetheless.by angry_octet
4/3/2026 at 12:12:02 PM
The main show are the techniques for writing portable shell scripts, not the compiler.If you want something one would actually use, try my project tuish:
by gaigalas
4/3/2026 at 12:22:49 PM
Is there a linter to ensure scripts are portable across shells? I try to write them like that but I'm certainly no master so I write them to work with busybox.by honkcity
4/3/2026 at 12:40:05 PM
A linter, not yet.You can use what I use: https://github.com/alganet/shell-versions
It's a container with lots of shells that you can test. Like esvu but for the shell.
Might have a little outdated docs, hit me with an issue if you use it and face any problems (I'm also the author).
by gaigalas
4/3/2026 at 10:34:17 PM
I think shellcheck helps quite a lot, you must set type to "sh" (not bash) somewhere in the comments though...by pvtmert
4/3/2026 at 5:08:52 AM
Why not POSIX or some common external tools where it makes sense? Most of those big switch statements could be easily replaced with some standard programs that already exist everywhere.by t-3
4/3/2026 at 7:07:34 AM
One main reason is performance. Forking for other tools is very expensive.That said, using larger sed or awk programs instead of ad-hoc calls for small snippets would perhaps be net-positive for performance and readability.
I'm currently working on very strict bootstrap scenarios in which sed and awk might not be available, but a shell might be (if I'm able to write it). It is possible that in such scenarios, the fist send and awk versions will be shell-written polyfills anyway.
by gaigalas
4/3/2026 at 11:49:32 AM
> One main reason is performanceThis assumes the executed program is as fast or slower than the caller.
by MisterTea
4/3/2026 at 11:13:37 AM
Why not just use gcc which already exists everywhere?When you answer that, same answer. If you can't imagine any answer for that, then the answer won't be convincing or make sense even if anyone tried to articulate it. Which is fine. Everyone doesn't have to find meaning in the same things.
by Brian_K_White
4/3/2026 at 1:57:01 PM
Shell without a userland is like FORTH without the ability to define new words. It's really contrary to the whole idea of what a shell is. Bootstrapping in very constrained conditions makes some sense, but where would you have a POSIX shell and not a POSIX userland (or close equivalent) to work with? When I wrote a similar compiler in shell, I purposely offloaded everything I could to external tools and used the shell for composition, so I found the approach intriguing and wanted to ask. I wasn't trying to criticize or dismiss the project, I think it's really cool or else I wouldn't have bothered to read the code in the first place.by t-3
4/3/2026 at 3:49:07 PM
Busybox it's what you need. On Forth, Subleq+EForth can do a lot more than you think.by anthk
4/3/2026 at 4:39:26 PM
gcc exists essentially everywhere a shell exists too. If you're ok with using grep and bc or whatever, then why not gcc?Or better yet, awk? awk is as old and ubiquitous as sh itself, on every machine even ancient ones that don't even have a compiler because that was a paid extra. Only unlike sh it's actually a full normal programming language that can do basically everything the shell can do only in a far more readable and sane way instead of using wierd expansions and abusing the command line parser to achieve functions it doesn't have overt functions for. Just write directly in awk the same way you would in say python or js. If you have sh, especially if you also have the userland you are talking about, then you have awk. It's part of that userland in a way that gcc is admittedly not.
More in your vein actually, when I do things like this I pick yet a different ideal goal than either you or the author. I avoid all externals (and even child shells) to whatever extent possible, but I do use bash for all its' worth. Every possible intentional or hack bashism. Require bash, but leverage bash to within an inch of it's life and require nothing else.
But this project tageting more portable code that doesn't require bash is really cool and valuable. Even though it's not a standard I personally shoot for even when I am specifically shell-golfing.
There are probably as many different points along the spectrum to draw the line as there are individual developers, each with some actually reasonbable argument to justify that particular place to draw the line.
To me using grep and sed and tr and ls and cat etc etc when I don't need them is just unsatisfying, inelegant, uninteresting.
If you are in bash or ksh93 or zsh, you don't need all kinds of things like basename, dirname, cut, tr, wc, nor some of the more powerful stuff either most of the time. I have a shell function that uses the built-in read combined with a named pipe file created in tmp to make a sleep that doesn't need /bin/sleep. Why bother? because it's awesome. And usually the only times I need to use sleep it's in some rapid short duration polling loop that really is better if you don't have to fork & exec & teardown on every iteration. It's bad enough to be polling like that in the first place. And it just doesn't matter how "probably all the externals will be there", not using them is even better. And these days a lot of once-common "userland" is no longer common or installed by default. A script that never tries to run dos2unix never cares that it's not installed, or that the bsd version behaves differently, or the mac version is stupid old, etc.
by Brian_K_White
4/3/2026 at 5:07:56 AM
gorgeous!by jonahx