Why I Use #5: GNU Tools, From Emacs to Arch Linux

Fifth in the series on the tools I reach for, and the first about tools I did not write: GNU's. Emacs, which I have used since 1989 as an editor, for a while as an IDE, as a shell, and as the place my own command-line tools plug in; GNU coreutils installed on the Mac with Homebrew, so its commands behave as they do on Linux; Arch Linux, where my agents now work, with gcc and the rest of the GNU toolchain; bash, and zsh on the Mac instead; and GNU's languages, from GNU APL to Guile, GNU Prolog and Octave.

The prior post in this series was about tools I wrote. This one is about tools I did not write but have built a working life around: GNU’s. Emacs most of all, and with it the GNU commands I install on the Mac, the GNU toolchain on the Arch Linux machines where my agents work, and GNU APL.

Resource	Link
GNU	gnu.org
Emacs	gnu.org/software/emacs
coreutils	gnu.org/software/coreutils
Arch Linux	archlinux.org
GNU APL	gnu.org/software/apl
The longer timeline	TBT #13: Many Decades of Learning the Next Thing
The series	Why I Use: every post
Comments	Discord

Emacs, since 1989

Emacs is one of the few bars on my career timeline that never ends: I have used it since 1989, vi since 1991 beside it, and for a few years around 2000 Emacs was my IDE as well as my editor. Since 2015 I have also used it as a shell, and since 2025 as an AI client.

I still prefer it for literate programming. Org mode and its Babel, which runs code blocks in many languages inside one document, suit me better than other notebooks such as Jupyter’s. In the same spirit, I am porting Reva’s notebooks, which ran on 32-bit Windows, to the Rust-based reva-fork, so they run on Arch Linux, in Chrome and on the Mac.

Emacs as the place my tools plug in

Emacs is where my own command-line tools meet. pjmai-rs and reg-rs both have Emacs packages, so switching projects and running regression tests happen in the editor as well as the terminal. X_eTaL has an Emacs mode that highlights and draws its notation, with Org Babel support so X_eTaL runs inside literate documents (Array Languages #19). And when my languages need glyphs, for APL, Tuplet and X_eTaL, Emacs has its own input methods for them: TeX-style and Agda-style mappings and a custom Quail input method (Saw #8).

GNU commands on the Mac

macOS ships BSD versions of the basic commands, which differ from GNU’s in their options and their output. So on the Mac I install GNU’s with Homebrew:

brew install coreutils

Homebrew installs them with a g prefix (gls, gdate, gsed for its separate gnu-sed) so they do not replace the system’s, and scripts and habits from Linux then work the same on both.

Arch Linux and the GNU toolchain

My agents now work on Arch Linux machines, one user per agent, reached from the MacBook with mosh and tmux (Saw #7, AI Tools #4). There the GNU toolchain is the ordinary one: gcc and the rest of Arch’s base-devel group for building, with GNU’s userland, coreutils, bash and glibc, underneath. Arch itself is not all GNU, though. A Linux distribution is many projects under many licenses: the Linux kernel under GPLv2, GNU’s tools under the GPL and LGPL, and plenty of packages under BSD, MIT, Apache and other permissive licenses. Arch records each package’s license in the package itself (pacman -Qi shows it).

bash, and zsh on the Mac

bash is GNU’s shell, the Bourne Again SHell. With sh and ksh before it, it has been on my timeline since 1991, and it is the shell on the Arch machines. On the Mac I use zsh, which is not GNU. It has been the macOS default since Catalina in 2019, and the bash Apple still ships is version 3.2, from 2007: the last release under GPLv2. Later versions moved to GPLv3, and Apple’s copy stayed where it was. Homebrew has a current one (brew install bash) for scripts that need it.

For both shells, and history in particular, I generally use the default settings.

GNU languages

When I recreated my first program, a 1972 horse race in APL, it was GNU APL that recreated it. GNU’s other languages are just as much a part of my toolbox: C and C++ through gcc and g++, Scheme through Guile, Prolog through GNU Prolog, numerical work in GNU Octave, text processing in gawk, and Common Lisp in GNU CLISP. For future embedded language projects I may use more of them as references, among them g77 for Fortran 77, GNU Pascal (gpc), and MIT/GNU Scheme.

Other GNU tools I use

Shell and text: sed, grep, findutils (find, xargs), diffutils (diff, cmp), patch, tar, gzip, less, readline (the line editing in many REPLs)
Building: make, gcc and g++, binutils (ld, as, objdump), gdb, autoconf, automake, libtool, m4, bison, texinfo
Libraries: glibc, ncurses
Everything else: wget, GNU parallel, and GNU screen, which I used before switching to tmux
Licenses: the GPL itself, from the other side: my reva-fork keeps copyleft code out, so it can be used commercially

Not every GNU tool

I do not like every tool on that list. I have been burned by Makefiles, where a recipe line must start with a tab and spaces that look the same break the build, so I prefer many of the newer build tools, lately just, a command runner written in Rust. And I have had portability problems between the Mac’s BSD sed and GNU sed on Linux, so I wrote sed-rs to behave the same on both.

GNU’s commands are also my test bench. When I build a new programming language, I often test it by writing simple versions of GNU command-line tools in it, such as cat, head, tail and wc.