getnf installs Nerd Fonts from the terminal

A shell script rather than a font manager

getnf describes itself as a better way to install Nerd Fonts, and the repository shows exactly what that means. The project is a Shell project, the primary language is Shell, and the tree is small.

At the root there is a single file called `getnf`, which is the program, and an `install.sh` that installs it. Around them sit a `Makefile`, a `man/` directory holding the manual page, a `packaging/` directory with the package definitions, a `docker/` directory with the test images, an `assets/` directory, and a `CONTRIBUTING.md`.

That is the whole shape of it, and it is a deliberate choice. Nerd Fonts are patched versions of ordinary fonts that add icons for developer tools, and the usual ways of getting them are a desktop font manager, a package in a distribution's repository, or downloading archives by hand from the Nerd Fonts site. getnf replaces the third of those with a script that knows where the archives are, which ones are installed, and how to put them where the system expects them.

The supported platforms are macOS and Linux, and the requirements are deliberately minimal. You need `curl` to fetch things, and `fzf` is listed as optional, which turns out to matter for the interactive experience rather than the installation itself.

The audience is a developer or a system administrator who installs fonts on their own machine or on a fleet of them, and who wants the process to be repeatable and reviewable rather than a set of clicks in a settings panel.

Installing getnf is a curl into your PATH

The install step assumes one thing about your environment, which is stated before anything else: make sure that `~/.local/bin` is in your PATH.

The installation itself is a single command.

curl -fsSL https://raw.githubusercontent.com/getnf/getnf/main/install.sh | bash

If you want to pass options to the installer, the pipe target takes them after a separator.

curl -fsSL https://raw.githubusercontent.com/getnf/getnf/main/install.sh | bash -s -- <options>

There are two options, and they are the ones you would expect. `--tag=<tag>` installs a specific release, for example `--tag=v0.3.0`, and `--silent` or `-s` suppresses the installation output.

curl -fsSL https://raw.githubusercontent.com/getnf/getnf/main/install.sh | bash -s -- --tag=v0.3.0
curl -fsSL https://raw.githubusercontent.com/getnf/getnf/main/install.sh | bash -s -- --silent
curl -fsSL https://raw.githubusercontent.com/getnf/getnf/main/install.sh | bash -s -- --tag=v0.3.0 --silent

Pinning a tag is the option that matters in practice. The `main` branch installer fetches the latest release, so an unpinned install is not reproducible, and the versioned form is what you want in a provisioning script.

There is also a table of other installation routes, and the range is worth noting. The Arch User Repository has a stable package installed with `paru -S getnf` and a development package, `getnf-git`. There is a Homebrew tap with `brew install getnf/getnf/getnf` for macOS and Homebrew users. `mise use -g github:getnf/getnf` works on both macOS and Linux, and `deb-get install getnf` covers Debian and Ubuntu. And the release assets themselves are available as a `.deb`, an `.rpm` or a `.tar.gz` for manual installation.

Six routes for a single shell script is a reasonable answer to the question of how many ways a Linux machine installs software.

The flags separate the menu from the scripted path

Running `getnf` with no arguments shows the font menu. The flags are what turn that into something you can drive from a script, and the documentation lists them all.

The listing flags are `-l` for the installed Nerd Fonts and `-L` for all the available ones, and the documentation is explicit that the exact names to use with the install and uninstall flags come from `getnf -L`. That is the one piece of information a user needs before anything else.

The install flags are `-i <font>` to install a specified font directly, with the same flag accepting several names either comma separated or as a single quoted space separated argument. The uninstall flags mirror that, with `-u <font>` for one or several fonts, and `-U` to update all installed Nerd Fonts at once. `-f` selects and installs using fzf, which is where the optional dependency earns its place, and `-a` includes the already installed fonts in the menu, which is what you want when you are deciding what to replace.

The remaining three are about scope and housekeeping. `-g` installs, uninstalls, lists and updates for all users rather than for the current one, `-k` keeps the downloaded font archives instead of discarding them, and `-V` prints the current version.

That is a well designed flag set for a small tool. The interactive menu and the scripted path use the same operations, so a person and a shell script end up doing the same thing rather than the script hitting a different code path.

A font cache is why nothing seems to change

There is one operational note in the documentation, and it is the one that catches out most people.

In case you cannot see newly installed fonts in your application, you may need to update the font cache with `fc-cache -f`. The fontconfig cache is what the system uses to answer the question of which font files exist, and a long running desktop session can hold a stale answer even after new files have been copied into place.

The same note explains one of the flags. The `-k` option keeps the downloaded font archives, which is useful if the installed font is not behaving as expected and you want to inspect or reinstall from the original archive.

The all users flag, `-g`, deserves its own note because it is the one that changes where things are written. Installing for all users means writing to a system font directory rather than the per user one, and that normally means elevated privileges. It is also the flag that makes getnf useful to a system administrator provisioning machines, as opposed to a developer fixing their own terminal.

Uninstallation is documented in the same practical spirit. To remove getnf without deleting the installed fonts, you remove the binary and its data directory.

rm -rf ~/.local/bin/getnf ~/.local/share/getnf

The font archives are left in the Downloads folder, and there is a command for removing them that copes with the fact that the download directory is not always called Downloads.

rm -rf "$(command -v xdg-user-dir >/dev/null && xdg-user-dir DOWNLOAD || printf '%s\n' "$HOME/Downloads")/getnf"

The `xdg-user-dir` lookup with a fallback is a small piece of care that says the script was written by someone who has met more than one Linux configuration.

Deb, rpm and a container based test rig

The Makefile is where the project's engineering practice shows, and it is worth reading even if you install the script with curl.

The version is not stored in the Makefile. It is parsed out of the script itself with a `sed` expression that pulls the `readonly VERSION` line out of the `getnf` file, and a dev suffix is stripped to produce the semantic version and the release tag. One source of truth for the version, which is the right way to do it and which avoids the release forgetting to bump a number in two places.

The `packages` target builds both a Debian and an RPM package with `nfpm`, using the two configuration files in `packaging/`, and produces a gzipped man page from `man/getnf.1` at the same time. The `images` target then builds two container images from the `docker/` directory, one based on Ubuntu 24.04 and one on Fedora 44, and the `test` and `ftest` targets open an interactive shell in each of them. So the packages are tested in both a Debian family and a Red Hat family environment, and the `ci-test` target smoke-tests the built image.

The distribution is therefore two real packages, a script, a manual page and a test matrix. The packaging directory also has a `nfpm-deb.yaml` and a `nfpm-rpm.yaml`, and the Makefile even rewrites the shebang when building the package copy, changing `#!/usr/bin/env bash` to `#!/bin/bash` and stripping the dev suffix from the version, with a comment explaining that this fixes an env-script-interpreter error reported by rpmlint.

That level of attention to a packaging warning is a reasonable proxy for how a project is being run.

Where a script is the wrong answer

The limitations are the ones you would expect from a tool of this size and shape.

The first is that the platform list is short. macOS and Linux are supported, and that is it. A Windows user is out, since the supported platforms are macOS and Linux.

The second is that it installs by name, which sounds trivial and is not. `-i` and `-u` take font names, and the exact spelling of those names has to come from `getnf -L`. A script that installs a fixed list of fonts therefore has to be generated from the available list, and if upstream renames or retires a variant, that script breaks. The alternative approach is to pin the font archives themselves, which is a different design and a different amount of work.

The third is the update model. `-U` updates all installed Nerd Fonts, which is convenient and also means the set of installed fonts drifts over time as upstream publishes new variants. There is no pinning mechanism described for keeping a particular version of a particular font, which matters if a design depends on a specific glyph being present or absent.

The genuine alternative is to skip the tool and manage fonts with whatever your platform already provides, a package manager on a Linux distribution, a font manager application, or a configuration management system for a fleet. The difference in approach is that getnf is a single script that knows about one specific upstream project and one specific archive layout, which makes it precise and easy to read, while the platform tooling is generic, so it is less convenient for this one job and more capable for everything else.

For a personal machine, the script wins on convenience. For a fleet, the choice depends on whether the fleet already has a configuration management system, because a font install is exactly the kind of task that belongs inside one.

Editorial conclusion

getnf suits someone who wants a specific patched font rather than a whole font family, and who prefers a script they can read to a desktop font manager. It is the wrong tool for a machine that needs a specific font variant pinned across many machines, because the tool installs by name and updates to the latest, and the wrong tool on a platform other than macOS or Linux. Check first the exact font names with `getnf -L`, and after installing run `fc-cache -f` if the application does not pick the new font up, since the cache is the usual reason nothing appears to change.

Frequently asked questions

Official sources

1. getnf/getnf on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases