unflab

Small, self-contained macOS command-line tools. One download each, no
package manager, and nothing installed that the tool doesn’t actually
need.

curl -fsSL https://unflab.app/get | sh -s -- tree

That installs tree into ~/.local/bin. Several at once works too:

curl -fsSL https://unflab.app/get | sh -s -- wget jq tree

No Homebrew. No Xcode. No runtime dependencies. All packages need to
work on a modern, freshly-installed Mac.

• Skip to the package list

Why

Wanting one small tool and getting a dependency tree is the normal
experience:

• brew install poppler, to extract text from a PDF, brings cairo,
  glib, nss, nspr, gpgme, fontconfig, freetype, libtiff, openjpeg,
  little-cms2 and 13 binaries.
• brew install gnuplot brings the entire Qt stack — qtbase,
  qt5compat, qtsvg — plus cairo, pango, glib, lua and harfbuzz.
• brew install bloaty, a tool for measuring binary size, brings
  abseil, protobuf, capstone and re2 and requires the whole cmake
  build toolchain.
• brew install inetutils, because macOS removed ftp and telnet,
  installs about 23 executables.

None of that is Homebrew’s fault — a formula has to serve every build of
a package. But when you want one tool, for one job, it’s a lot of
machinery to acquire and keep updated.

Currently built for Apple Silicon only; as Intel support is deprecated
the build platforms have started to diverge, meaning that they’re becoming
different targets.

What about webi?

webinstall.dev covers a lot of the same
ground: curl … | sh, installs into ~/.local, no package manager, no
root. If you already use it, keep using it — this isn’t an argument that
you picked wrong. webi is great.

The differences are real, though, and they’re mostly about scope:

• webi downloads, unflab compiles. With one exception: ffmpeg is
  Martin Riedl’s signed static build, which the installer downloads and
  accepts only if it matches a pinned checksum and his Developer ID
  signature, and which goes through the same gate in CI.

• webi is multi-platform, unflab is macOS-only.

• Different rosters. webi leans towards web-dev tooling; unflab
  leans towards Unix plumbing.

• unflab checks what it ships. unflab puts every binary through the
  otool -L gate in CI, whereas webi uses the official binaries.

The upshot is that unflab can provide a specific utility from a larger
package. In fact, that’s the reason for all this: I needed timeout (a.k.a
gtimeout) from GNU coreutils, but didn’t want to install the whole thing.

None of that makes them mutually exclusive, and I’d recommend using webi
for most packages, especially larger ones where you actually want the larger
suite. So it’s packaged here too:

curl -fsSL https://unflab.app/get | sh -s -- webi

…just so you don’t have to additionally look up webinstall.dev
for the command.

What “self-contained” means

macOS has no static libSystem and doesn’t support fully-static
executables, so nothing here claims to be statically linked. What every
binary is checked for, in CI, before release:

it links against nothing outside /usr/lib and /System/.

That’s scripts/verify.sh, and a failure fails the build. Homebrew may
be used on the build machine to get a static library or a tool; the gate
is what proves none of it survived into what you download.

The unflab command

Installing anything also drops a small unflab script beside it, so you
don’t have to find that curl line again:

unflab jq mlr                 # install more
unflab --uninstall ftp        # remove one
unflab --purge doggo          # remove it and its config files
unflab --list                 # see what there is
unflab --info jq              # read a utility's page
unflab unflab                 # update this helper

It is not a package manager and doesn’t want to become one. It keeps no
database, records no state, and updates nothing behind your back — it
re-runs the same one-liner you started with, so you don’t have to retype
it.

Delete it if its presence offends you; nothing depends on it, and

curl -fsSL https://unflab.app/get | sh -s -- <utility>

does everything it does.

Available now

Installed using their own installers

Not built here. get shows the command and asks before running it.

coreutils (105)

Not in unflab

Asked for often enough to say why not, and where to get them instead.

Installing manually

Each package ships its own install.sh. The curl | sh line above runs
it for you; a manual download runs the same script, the same way:

tar xzf unflab-tree-2.3.2-arm64-apple-darwin.tar.gz
./install.sh                        # into ~/.local/bin
./install.sh --prefix /usr/local/bin
./install.sh --uninstall            # remove it
./install.sh --purge                # and its config files

It won’t touch your shell config without asking, it won’t overwrite a
command you already have, and it won’t remove a file it didn’t install.

Building it yourself

The intention is that you just download the GitHub CI binaries. After
all, keeping your Mac clean of all that build nonsense is one of the
primary goals… GitHub’s CI runners have all the tools necessary to
build these utilities so you don’t have to.

However, if you want to use this repo for your own builds; add to it (yes
please); or are just suspicious (fair enough), then:

make                  # list the recipes
make packages         # list every installable package
make wget             # what you can do with one
make wget.prereqs     # what building it needs
make wget.build       # fetch, verify, build, gate
make wget.install     # install what you just built
make wget.package     # make a release archive

Targets take either a package name or a recipe name, which matters where
one recipe builds several packages:

make ftp.install         # just ftp
make inetutils.install   # everything that recipe builds (ftp, telnet)
make coreutils.install   # the whole suite, if you really want it
make timeout.install     # builds coreutils, installs only timeout

Recipes live in utils/‹name›/: recipe.sh pins the upstream source and
its SHA-256, and manifest.tsv says what gets installed where. Building
without a pinned checksum is refused.

make ‹util›.prereqs will tell you what’s missing, but won’t install a
large toolchain behind your back — needing one to build a 50KB binary
would rather defeat the point.

Licence

This repository’s own code — the recipes, the installer, the workflows —
is MIT (see LICENSE).

Every utility it builds stays under its own upstream licence, shipped
verbatim inside the package. unflab compiles and packages other
people’s software; it doesn’t relicense it. Each recipe records the exact
source URL, version and checksum it was built from — or, for a binary it
installs rather than builds, the URL and checksum of that binary.