coreutils: a comprehensive review (2023)

GNU coreutils forms the backbone of every Linux and Unix-like system. These 100+ utilities handle core tasks: copying files with cp, listing directories with ls, managing processes, and evaluating conditions. Installed by default on distributions from Ubuntu to RHEL, coreutils processes billions of invocations daily across servers, desktops, and embedded devices. A 2023 review tackling them alphabetically reveals quirks that script writers and admins ignore at their peril.

Start with the essentials: [ and test. Both evaluate expressions and exit with 0 for true/success or 1 for false/failure. Empty arguments fail; anything else succeeds. Test it in bash:

$ test; echo $?  # Outputs 1
$ test 1; echo $?  # Outputs 0
$ test ""; echo $?  # Outputs 1
$ if test 1; then echo 'true'; else echo 'false'; fi  # Prints true

Bash supplies built-in versions by default, shadowing the coreutils executables. Bash’s [ chokes on --version because it expects a closing bracket:

$ [ --version
bash: [: missing `]'

Force the coreutils binary with full path:

$ /bin/[ --version
[ (GNU coreutils) 8.25
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Kevin Braunsdorf and Matthew Bradburn.

Coreutils installs both as distinct executables—no symlink. On a typical system, their MD5 sums differ:

6e6588788b3ec5110b4532f8f1d912e3  /bin/[
76db2a10639424c0ba7c09c9d6626ec5  /bin/test

Source Code Nuances

Dig into the GitHub mirror (github.com/coreutils/coreutils/src): both stem from test.c. The [ variant compiles lbracket.c, which defines LBRACKET 1 and includes test.c. This tweak handles --help and --version uniquely: [ --help shows output, but test --help exits silently per POSIX. POSIX demands test --help fail quietly, while allowing GNU-style options for bracket form.

Minimal differences exist between bash builtins and coreutils versions—man pages align closely. But builtins run faster, avoiding execve overhead. In tight loops or shebangs, prefer builtins unless POSIX purity demands externals.

Security and Practical Implications

Why dissect this? Scripts rely on predictable exit codes. A manipulated PATH could swap test for a trojan, altering logic in cron jobs or daemons. Coreutils CVEs hit regularly: CVE-2023-28531 in chown allowed symlink attacks; older ones like CVE-2017-7476 in base64 exposed info leaks. Check your distro’s version—Ubuntu 22.04 ships 8.32, Fedora 39 uses 9.1, while upstream hit 9.4 in 2023. Audit with coreutils --version; lag exposes systems.

Beyond [ and test, arch prints the machine hardware name, akin to uname -m. On x86-64, it outputs x86_64. Deprecated since 2004, it persists for legacy scripts. Use uname instead—more options, standardized.

Coreutils’ monolithic size (over 1MB source per tool on average) invites bloat. Static linking bloats containers; musl libc variants slim images 30-50%. For security pros, compile from source with hardening flags: -fstack-protector-strong -D_FORTIFY_SOURCE=2. Forked alternatives like BusyBox cut attack surface for IoT, trading features for 10x smaller footprints.

This matters because coreutils underpins automation. A flawed cp cascades to backups; buggy conditions derail if-then logic in 80% of shell scripts (per GitHub analysis). Stay current, prefer builtins, full-path critical binaries. Next in alpha: base64, basename. Coreutils endures because it works—flaws and all—but vigilance pays.