Install zenity with Homebrew, apk, apt, dnf, MacPorts, Nix, pacman, zypper

Project links

• Homepage

Commands and aliases

• zenity

Project history

Zenity descends from GNOME's `gdialog` lineage. The GNOME README calls it the GNOME port of the venerable `dialog` program, while older BLFS documentation for Zenity 2.6.2 described it as a rewrite of gdialog, itself the GNOME port of dialog for displaying GTK+ dialog boxes from command-line scripts.

The old GNOME 2 era packaging already shipped both `gdialog` and `zenity`, with `gdialog` kept as a wrapper for legacy scripts. The modern repository still carries that role forward but has moved with the GNOME platform: the README identifies Zenity as part of GNOME Extra Apps and lists GTK 4 and libadwaita as current dependencies.

Because its purpose is deliberately small, Zenity has stayed stable in concept for decades: a CLI command that turns script state into desktop UI. Its evolution is mostly GNOME toolkit migration, option compatibility, and the set of supported dialog types.

Adoption history

Zenity became widely adopted because it solved a packaging and scripting problem that neither pure terminal tools nor full GUI frameworks solved cleanly: a shell script could request desktop input using a standard GNOME/GTK utility. That made it attractive for installers, admin scripts, small desktop helpers, and distribution glue.

The supplied package data shows Zenity available across Homebrew, Debian, Ubuntu, Fedora, Alpine, MacPorts, Nix, Arch, and openSUSE-family packaging. That breadth reflects both its age and its continued usefulness as a tiny dependency for desktop-facing shell workflows.

How it is used

Common usage is direct from shell scripts: `zenity --info`, `--warning`, `--question`, `--entry`, `--file-selection`, `--progress`, `--list`, `--calendar`, and similar options show GTK dialogs and return either exit status or selected/input data to stdout.

Zenity is especially useful where a package maintainer or script author wants a lightweight graphical prompt without adding a bespoke GUI. It is less useful on headless systems or non-GTK desktop environments unless the needed display and runtime stack are present.

Why package nerds care

Zenity is a classic package-nerd utility because it sits at the boundary between CLI automation and desktop integration. It is often installed not because users launch it directly, but because scripts and packages want a standard, cross-language way to display GTK dialogs.

It is also a reminder that small desktop commands have long compatibility tails. The `gdialog` wrapper, old GNOME 2 documentation, modern GTK/libadwaita migration, and broad distro packaging all show how a tiny CLI can persist as infrastructure.

Timeline

• GNOME 2 era: Zenity appears as the rewrite/replacement for gdialog while retaining a gdialog wrapper for legacy scripts.
• 2004: BLFS 5.1 documents Zenity 2.6.2 as a GNOME additional package for command-line GTK dialogs.
• 2020s: GNOME repository identifies Zenity as a GNOME Extra Apps project using GTK 4 and libadwaita.
• 2022: Oracle Solaris man page documents the broad Zenity/gdialog option set, including file selection, progress, list, forms, calendar, and notification dialogs.

Related projects

• dialog is the text-mode dialog program that inspired the GNOME/GTK lineage.
• gdialog is Zenity's predecessor and legacy wrapper name.
• KDialog provides a comparable script-facing dialog tool in KDE environments.

Sources

• https://docs.oracle.com/cd/E88353_01/html/E37839/gdialog-1.html
• https://github.com/GNOME/zenity#readme
• https://www.linuxfromscratch.org/blfs/view/5.1/gnome/zenity.html
• source_facts.package-manager