Why is everything in the same binary? Why not multiple binaries, one for each function? That way people can install only the ones they need, a-la Unix tools: do only one thing and do it well.

I also have the exact same tools but written in Go. Rust would be a nice upgrade (lower footprint) but to keep them all in the same binary is a bit silly.

The single binary thing reminds me of BusyBox - https://en.wikipedia.org/wiki/BusyBox

Sometimes it can be quite convenient to grab a single binary that does a whole bunch of useful stuff in one package.

Also, lots of the ut functions already exist as decades old unix tools.

Those tools either don't ship with, or exist in wildly different forms on Windows. It's particularly bad for curl, which might be the real curl.se curl or Microsoft's confusingly-named Powershell alias.

I could definitely see using this in a cross-platform build or installation environment.

Windows and *nix systems are often used for very different things so I don't understand why there would be need for some kind of universal superbinary. And thanks to WSL you can already get GNU coretools running in Windows anyways.

I lead a large-ish open source software project. We have developers that need to build on Linux, macOS, and Windows. It's useful to be able to get everyone bootstrapped with as few steps as possible and with as few dependencies as possible. For our uses CMake works well as a universal superbinary, but I'm always on the lookout for tools that can reduce developer friction.

Gerald Combs of Wireshark? Wow, thanks for all your hard work!

Probably for the same reasons that uutils/coreutils uses a single binary. Specifically:

- it reduces the total install size, since common code, including the standard library, is only included once, rather than copied for each executable

- it makes installation easier on some platforms, since you just have to install a single executable, instead of a bunch of executables

To me the biggest upside would be terminal completion and discovery via help text. Sure you can always bounce to a search engine and bounce back, but I can imagine cases where you want a toolkit in front of you that you know how to use when your focus is not on memorizing commands.

This could be great for students without sysadmins needing to lodge complaints.

I don't think it's that silly. BusyBox packages a bunch of utilities in a single binary. It amortizes fixed costs: a single binary takes less space than 30 binaries that each do one tiny thing.

These are small bits of code, and the functionality is interrelated. The entire thing feels like a calculator, or awk, and seems reasonable to put in one binary.

The Unix philosophy doesn't actually say anything about whether different tools should live in the same binary. It's about having orthogonal bits of functionality and using text as the universal interface. BusyBox is just as Unix as having all the tools be different binaries.

Amusingly, if you look historically, it's also a traditional approach to reduce total binary size - a bunch of small utilities were all Sim links to a single binary, which conditioned on argv[0] to figure out what to do.

In The Old Days, it was hard links, no symlinks.

Eek, you're right. Also ugh, I should stop talking to my phone, just noticed "Sim links". sigh.