Bunster: Compile bash scripts to self contained executables

Yes and no.

It does work - but there are some OS-specific stuff that can still pop up and explode on you. There are different guarantees around open/write on Windows and *nix, and cosmopolitan doesn't 100% paper over those gaping differences. It doesn't change the underlying file locking behaviour of the file system, for example. You can run into thread-time guarantees and other streaming problems, when piping from one thing to another.

Busybox commands often don't support all features used to and differ even substantially if you depend on GNU additions. https://www.busybox.net/about.html

I also wondered this as well. How is something like "cat file.json | jq '.filename' | grep out.txt" implement into Go?

I assume this is what they are talking about here:

> Standard library: we aim to add first-class support for a variety of frequently used/needed commands as builtins. you no longer need external programs to use them.

That's not going to be an easy task, and would basically entail porting those commands to go.

Disclamer: the elephant in the room has nothing to do with ElePHPant, the PHP mascot.

My problem with python is startup time, packaging complexity (either dependency hell or full blown venv with pipx/uv). I’ve been rewriting shell scripts to either Makefiles (crazy but it works and is rigorous and you get free parallelism) or rust “scripts” [0] depending on their nature (number of outputs, number of command executions, etc)

Also, using a better shell language can be a huge productivity (and maintenance and sanity) boon, making it much less “write once, read never”. Here’s a repo where I have a mix of fish-shell scripts with some converted to rust scripts [1].

[0]: https://neosmart.net/blog/self-compiling-rust-code/

[1]: https://github.com/mqudsi/ffutils

I have exactly the same issue. I maintain a project called discord.sh which sends Discord webhooks via pure Bash (and a little bit of jq and curl). At some point I might switch over to Go or C.

https://github.com/fieu/discord.sh

Yesterday, I had a problem where wget alone could do 98% of what I wanted. I could restrict which links it followed, but the files I needed to retrieve were a url parameter passed in with a header redirect at the end. I spent an hour relearning all the obscure stuff in wget to get that far. The python script is 29 lines, and it turns out I can just target a url that responds with json and dig the final links out of that. Usually though, yeh, everything starts as a bash script.

I agree. My limit is pretty much one you start branching or looping, it should be in another tool. If that seems low to you, that’s the point

I definitely agree. Bash is such an unpleasant language to work with, with so many footguns, that I reach for a language like Python as soon as I'm beyond 10 lines or so.

Isn't this perfect for LLM?

You know, assuming they transpile well, I haven't tried a solid one yet.

I wonder if kernel code rewrites in rust with Llama (obviously reviewed are up to snuff.

So it compiles to a single executable that I can send to someone who isn’t on Nix?

Because if I wanted a portable shell script, I’d just write shell and check if something is executable in my path.

This just looks like Nix-only stuff that exists in an effort to be ultra declarative, and in order to use it you’d need to be on Nix.

Nix is the best.

If you're reading this and wondering how you can use this for yourself?

You don't need nixos at all. You can install nix on any linux-like system, including on MacOS

Is it possible to override shellcheck? It's a valuable tool that I use all the time, but it reports many false positives. It's not unusual for junior developers to introduce bugs in scripts because they blindly follow the output of shellcheck.

I still haven't come around to using nix in my daily workflow. My concern is high entry bar, obscure errors and breaking changes, but also excessive use of storage either because that's how it works or because I won't know how to manage the store well.

How's nix these days? How long would you expect someone with years of Linux management experience (bash, ansible, terraform, you name it, either onprem or on cloud) to get comfortable with nix? And what's would be the best roadmap to start introducing nix slowly in my workflow?

Well you're still leaning on Nix to provide the dependencies. All `writeShellApplication` will do is prepend the `PATH` variable with the `bin` directories of the provided `runtimeInputs`, it still just spits out a bash script, not a binary that includes bash, the script, and the other dependencies. I reckon it's quite possible for someone to lean on Nix to implement producing an all-in-one binary though.

If your shell scripts/libraries are a little more complex, resholve can also help package them a little more reliably.

(I'd say it's overkill for your example here, but it blocks on missing dependencies and can support tricky cases such as modular shell libraries that expect different implementations of the same command.)

omg i love nix so much.

Oh. I was just about to comment that it may be easier to understand what it does by decompiling the binary than by looking at the actual unreadable Bash language ;-)

What does this do mate? (I tried to run it and it failed)

I think you’d have to say more. It looks quite sane to me.

This is has nothing to do with FOSS. Self-detonating code is a great idea, something my peers and I often joke about but rarely actually implement (though I have done depreciations that are similar).

Here's some FOSS just for you:

   /* Copyright (c) 2025 xyzzy_plugh all rights reserved.
   
   Usage of the works is permitted provided that this instrument is retained with the works, so that any entity that uses the works is notified of this instrument.
   
   DISCLAIMER: THE WORKS ARE WITHOUT WARRANTY.
   */
   if(time(NULL) > 1767225600) exit(1);