8 ms·

Single standalone file, no external tools used, PATH='' (empty), portable (bash, dash, ksh, zsh), produces x86 ELF executables, has mini-libc builtin. Usage:

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

angry_octet 7mo ago
I can't think of a reason to use c89cc.sh, but I salute this effort nonetheless.
- gaigalas 7mo ago
  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: http://github.com/alganet/tuish http://github.com/alganet/tuish
  - honkcity 7mo ago
    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.
    - gaigalas 7mo ago
      A linter, not yet. You can use what I use: https://github.com/alganet/shell-versions 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).
    - pvtmert 7mo ago
      I think shellcheck helps quite a lot, you must set type to "sh" (not bash) somewhere in the comments though...
jonahx 7mo ago
gorgeous!
t-3 7mo ago
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.
- gaigalas 7mo ago
  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.
  - MisterTea 7mo ago
    > One main reason is performance This assumes the executed program is as fast or slower than the caller.
- Brian_K_White 7mo ago
  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.
  - t-3 7mo ago
    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.

angry_octet 7mo ago

I can't think of a reason to use c89cc.sh, but I salute this effort nonetheless.

gaigalas 7mo ago
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: http://github.com/alganet/tuish http://github.com/alganet/tuish
- honkcity 7mo ago
  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.
  - gaigalas 7mo ago
    A linter, not yet. You can use what I use: https://github.com/alganet/shell-versions 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).
  - pvtmert 7mo ago
    I think shellcheck helps quite a lot, you must set type to "sh" (not bash) somewhere in the comments though...

jonahx 7mo ago

gorgeous!

t-3 7mo ago

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.

gaigalas 7mo ago
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.
- MisterTea 7mo ago
  > One main reason is performance This assumes the executed program is as fast or slower than the caller.
Brian_K_White 7mo ago
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.
- t-3 7mo ago
  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.