Gogh: A Shell Script That Repaints Your Terminal From a Theme Library

The gap Gogh fills between a palette and a working terminal

Picking colors is easy. Getting them into a terminal is not. Every emulator stores its palette differently: Gnome Terminal keeps profiles in dconf, Alacritty and Ghostty read a text config file, Cygwin and Mintty use yet another format. A color scheme that looks good in a screenshot has to be translated into each of those formats before it does anything.

Gogh's answer is a library of schemes plus a script that knows how to write each format. The README describes it as a collection of color schemes for terminal emulators across Linux and macOS, plus Cygwin/Mintty on Windows, and it links a Terminal Support table where each emulator maps to a specific function such as apply_alacritty(), apply_foot(), apply_ghostty(), apply_gtk() and apply_cygwin() in apply-colors.sh. That mapping is the product. The palettes are the payload.

The audience is narrow and practical: people who already know which terminal they use and want a different look without hand-editing config files, and people who set up machines repeatedly and want that look to be reproducible. It is not aimed at anyone building a theming system of their own.

How the installer decides what to write and where

The entry point is gogh.sh, and the heavy lifting sits in apply-colors.sh. Theme definitions live under themes/, with data/ alongside it, and the repository ships a requirements.txt listing unidecode, pyyaml and rich.

The flow is: fetch or clone the repository, pick a theme, detect or accept the target terminal, then dispatch to the matching apply_* function, which writes the palette in that terminal's native format. On dconf-based terminals the pre-install step installs dconf-cli and uuid-runtime (or dconf and util-linux on Arch), which is the clearest signal that Gnome-family support works by generating a profile and loading it into dconf.

A detail worth noting: the README documents a Color Hash section and a WCAG accessibility contrast section. That means contrast data exists for the schemes.

Installing Gogh and applying your first scheme

Install the prerequisites first. On Debian or Ubuntu the README gives this command, which brings in the dconf tooling and a UUID generator used for profile creation:

sudo apt-get install dconf-cli uuid-runtime

On Arch the equivalent is pacman with dconf and util-linux. Once those are present, the interactive installer is one line. The README shows the wget form for Linux and the curl form for macOS:

bash -c "$(wget -qO- https://gogh.website/gogh)"

Run it and you get an interactive list of themes to select from.

If you already know the name, pass it after a double dash. The README uses "Aci" as the example:

bash -c "$(wget -qO- https://gogh.website/gogh)" -- "Aci"

For scripting, dotfiles or container images, the README points to docs/NON_INTERACTIVE.md, which covers cloning the repo or downloading only the required files, selecting themes by name or slug as CLI arguments, and the environment variables TERMINAL, GOGH_NONINTERACTIVE, GOGH_USE_NEW_THEME and the GOGH_*_SCRIPT path overrides. Set TERMINAL when detection cannot identify your emulator; that variable is the documented escape hatch.

Where Gogh stops being the right tool

Gogh changes colors. It does not manage fonts, cursor shape, keybindings, window opacity or shell prompt. If your goal is a fully reproducible terminal configuration, Gogh covers one slice of it and you still need your own dotfiles for the rest.

The support table introduces itself as 'some terminals that Gogh is supported with', so check it for your emulator before relying on the script.

There is also a re-run question. The README documents installation, specific-theme installation and non-interactive installation, but the visible part does not show rollback or removal. On a machine where the existing palette matters, take note of your current settings before running anything.

Finally, the install path is a remote script piped into bash from gogh.website. That is convenient and it is also the standard reason people refuse this class of installer. Cloning the repository and running the local script is the alternative the non-interactive guide supports.

Gogh against hand-written dotfiles and base16-style generators

The obvious alternative is writing the palette into your terminal config yourself. For Alacritty or Ghostty that is a handful of hex values in a file you already version. The difference is scope: your dotfile covers one terminal and one machine, while Gogh carries the same scheme across Gnome Terminal, Pantheon, Tilix, XFCE4, Alacritty, Foot, Ghostty, Cygwin and iTerm on macOS. If you only ever use one emulator, the script is an extra dependency between you and a file you could edit directly.

The other family of alternatives is palette generators that derive a full theme from a single source color, producing coordinated values for the terminal and for applications. Gogh does not work that way. It ships fixed schemes authored by contributors, and the README points to docs/CONTRIBUTING.md for adding your own. The trade-off is consistency by curation rather than by algorithm: you get a palette someone designed and checked, and you do not get one tuned to a wallpaper or brand color.

There is a middle path in the repository itself. Because the theme data lives in themes/ and data/, and the apply functions are separate per terminal, you can read a scheme out of the repository and paste it into your own config, using Gogh as a catalog instead of an installer.

Maintenance, licensing and what upgrading costs you

The repository is not archived, and the last push was on 2026-10-23. Releases are frequent and named after theme counts, with v1251 (Themes 1251) on 2026-10-23 and v1250 and v1249 on 2026-10-01. That cadence is the shape of the project: themes accumulate, and the installer changes less often than the catalog does.

Upgrade cost is therefore low in the common case. Re-running the installer picks up new schemes. The risk sits in the Python dependencies pinned in requirements.txt (unidecode, pyyaml and rich, all unpinned) and in the config-file writers: if your terminal's format changes, the apply function for that terminal has to change with it. The repository includes tests/docker/ entries per terminal, which is where that compatibility work is exercised.

On licensing, the repository root contains LICENSE, LICENSE-APACHE and LICENSE-MIT, and the GitHub metadata reports the licence as NOASSERTION, meaning GitHub could not classify it automatically. That combination is worth reading before you redistribute the themes inside a product. This is not legal advice: read the three files yourself.

Editorial conclusion

Adopt Gogh if you run one of the terminals in its support table and want a palette applied in a single command, or if you provision machines and need the documented non-interactive path. Skip it if your terminal is not one it supports, or if you need the script to manage anything beyond colors. Before rolling it out on a fleet, read docs/NON_INTERACTIVE.md and confirm the TERMINAL value for your emulator, then run the installer once on a throwaway profile and check that your existing color settings are the only thing it touched.

Frequently asked questions

Official sources

1. Gogh-Co/Gogh on GitHub
2. Issues
3. Project website
4. README
5. Releases