Announcing utils-std: A collection of commonly available Unix tools
Many years ago after being annoyed at both BusyBox and GNU coreutils, I started replacing few utilities like true(1)
/false(1)
, as well as date(1)
.
This was rather slow paced, merely replacing utilities when I wanted a better version of them.
Then I picked up the pace after looking into full-source system bootstrapping. As I thought it would be pretty cool to get proper utilities easily, most importantly not require old versions for this kind of ordeal. Otherwise we could easily end up locking ourselves to both old operating systems and old CPU architectures/platforms.
Links
- Git repository
- Webview of the manpages
- Tarballs (only snapshots for now)
The problems with GNU coreutils
Frankly I find GNU coreutils to be horrible.
Yes, it's cat(1)
and yes(1)
implementations are so long and weird they became meme material but they're at least somewhat acceptable. The true pains are:
true --help >/dev/full
andtrue --version >/dev/full
fails, so you can't rely on true as a no-op utility- The
--date
option of GNU date is based on natural language processing, don't rely on it, you'll end up with nonsense results that at first sight could look fine instead of errors cut -c
doesn't works with multibytes codepoints (aka character runes). Working with characters rather than bytes (-b
) is the whole reason-c
exists…- Awful manpages: join(1) and paste(1) are barely described at all, tsort(1) is essentially a placeholder
rm(1)
implementation is a mess, you end up with massive functions shared between utilities dealing with options logic and user-prompt parsing instead of separating functions per-fonctionality and having logic like user-prompts being their own functions
Is utils-std entirely from scratch?
Nah. I picked up few utilities from FreeBSD/OpenBSD/NetBSD. I picked sha{1,256,…}sum from sbase, …
In fact part of why utils-std default license is the MPL-2.0 and not a GPL license is to be able to easily pick up code from other projects without some kind of license incompatibility problem.
But why not use BusyBox/Toybox/sbase/chimera-utils/… ?
BusyBox/Toybox
- Buildsystem heavily depends on GNU Make and GNU Bash
- Severely lacking. It's typical to install coreutils on Alpine systems to simply get POSIX fonctionality
- Stuck on reimplementing everything, specially ToyBox due to it's 0BSD licensing
- While there is a busybox manpage, it's equivalent to concatenated
--help
output, and a single manpage with 100+ utilities isn't easy to browse
sbase
- Pretty good in terms of dependencies
- Also seems severely lacking, including against POSIX fonctionality
I also don't really vibe with suckless.org ethos: Minimalistic to a degree where usability suffers, and code that I find lacking when it comes to error handling.
chimera-utils
- Depends on at least meson/ninja, flex, byacc, libxo
- Soft-fork of FreeBSD utilities so even better than the baseline of POSIX fonctionality (although that can mean BSD-isms vs. GNU-isms)
I would use it if the dependencies wouldn't mean breaking bootstrapping from source, and I would recommend it as an alternative, specially against BusyBox/Toybox/sbase.