Every tui-tools tool in one place, installed through your package manager
A terminal UI (TUI) for pacman, apt and dnf on Linux: the launcher of the tui-tools family.
v0.2.1betapackagesMIT
The dashboard: every tool of the family, what this machine has, and what the repository offers
The launcher of the tui-tools family. Every tool of the family is a card: what it does, whether this machine has it, which version, and whether the repository offers a newer one.
A second group holds the companions: family packages that are not terminal UIs, and upstream projects rebuilt under the family provenance gate. The row says which repository the installed copy came from; o switches it to the family's build.
Install, update and remove go through the distribution's own package manager — apt, dnf or pacman — each previewed as the exact command line and confirmed before it runs. enter hands the terminal to an installed tool and takes it back on exit.
The catalog it reads only says which packages exist. It never decides what reaches the machine: your package manager verifies the signed repository index and the signed package, and every package name in it is validated twice before it can reach a command line. A snapshot of it is built into the binary, so the dashboard works offline.
s sets the repository up, with the key pinned by fingerprint.
Run tui-tools --demo for a sample machine where every key works and nothing is touched.
Keys
Key
Action
enter
Launch the selected tool; on a companion, show its full status instead
i
Install it, through this machine's package manager
u
Update it
x / d
Remove it; nothing it pulled in is autoremoved
o
Switch a companion to the tui-tools build, when it came from elsewhere
s
Set the tui-tools repository up, with the key pinned by fingerprint
r
Re-read the catalog and the machine
/
Filter by name, tagline, category or state
?
Help
q
Quit
Press ? inside the tool for the full help screen, which is generated from the same action table as the key map.
Compatibility
This tool is a face on the program below, so its version matters.Tested is not a claim: a version lands there only after the tool's own suite passed against it on a real machine in the lab, and the run is kept as evidence in the repository. At startup the tool probes the backend once and says what it found in its header — a version nobody has run against is shown as(untested) in the warning colour, one older than the minimum as (below minimum) in the error colour. Neither stops it: the backend still refuses what it cannot do, in its own words.
pacman
pacman ≥ 6.0
Binary
pacman
Minimum
6.0
Probed with
pacman --version
Tested
No recorded run yet. The tool still runs and reports the version it found as untested.
What changes on older versions
pacman >=6.0
Arch has no supported way to upgrade one package against a refreshed database without upgrading the machine with it, so an update here is pacman -Syu with the tool named, and the confirm dialog says so before it runs
pacman >=6.0
the repository setup writes a [tui-tools] section under /etc/pacman.d and adds one Include line to pacman.conf, so a later setup finds it again instead of appending a second block
pacman >=6.0
pacman records no repository for an installed package, so a companion's origin is inferred rather than read: a bare [installed] in pacman -Sl tui-tools means the machine has the version that repository offers, and pacman -Si names the repository whose version matches the installed one
apt
apt ≥ 2.0
Binary
apt
Minimum
2.0
Probed with
apt --version
Tested
No recorded run yet. The tool still runs and reports the version it found as untested.
What changes on older versions
apt >=2.0
the available version comes from apt-cache policy, which reads the lists already on disk; a repository added a moment ago reports nothing until the refresh, which is the first previewed step of an install rather than something the read path does behind you
apt >=2.0
a companion's origin is read off apt-cache policy: the version marked *** is the installed one, and the first source under it that is not /var/lib/dpkg/status is where it came from. apt cannot install from a named repository, so a switch names the family's version instead
dnf
dnf ≥ 4.0
Binary
dnf
Minimum
4.0
Probed with
dnf --version
Tested
No recorded run yet. The tool still runs and reports the version it found as untested.
Needs a version this new
dnf5since 5.0
What changes on older versions
dnf >=5.0
dnf --version prints dnf5 version 5.2.18.0, where dnf4 prints a bare 4.24.0 on its first line; both are read by the same pattern, which keeps three components because a four-part version is not one the family schema records
dnf >=4.0
the available version comes from dnf repoquery, which answers from the cache on disk, so a machine whose metadata has expired reports what it last fetched rather than refreshing behind you
dnf >=4.0
dnf is the one manager that records where an installed package came from, so a companion's origin is read rather than inferred: dnf repoquery --installed --qf '%{name}|%{from_repo}' answers it on dnf4 and dnf5, and @System means it came from a file
Install
Once per machine, then every tool in the family is one pacman away.
Add the repository
$ curl -fsSL https://pkgs.tui.tools/install.sh | sh
Or run the same thing yourself, one command at a time
A family whose whole promise is preview before you run is not going to insist you pipe a script into a shell. These are the commands that script runs.
Upgrades then arrive with the rest of your system updates.
!
Not published yet. The command is what it will be once the package repository at pkgs.tui.tools is live. Until then, use the static binary or build from source.
Arch Linux (AUR) · tui-tools-bincoming soon
$ paru -S tui-tools-bin
The -bin package installs the released static binary.
Once per machine, then every tool in the family is one apt away.
Add the repository
$ curl -fsSL https://pkgs.tui.tools/install.sh | sh
Or run the same thing yourself, one command at a time
A family whose whole promise is preview before you run is not going to insist you pipe a script into a shell. These are the commands that script runs.
Upgrades then arrive with the rest of your system updates.
!
Not published yet. The command is what it will be once the package repository at pkgs.tui.tools is live. Until then, use the static binary or build from source.
Needs the tui-tools repository, a one-time setup you do once per machine.
openSUSE · tui-toolscoming soon
$ sudo zypper install tui-tools
The rpm repository is shared with dnf; zypper support is not tested yet.
One static binary. Verify it against checksums.txt from the same release.
From source · tui-tools
$ git clone https://github.com/tui-tools/tui-tools
cd tui-tools && make build
sudo install -m0755 bin/tui-tools /usr/local/bin/tui-tools
Needs Go 1.27 or newer.
What it can do to your machine
✓
Preview, then confirm
Every change is shown as an exact command line and confirmed before it runs. The dialog and the runner receive the same value, so the preview cannot drift from what executes.
•
Escalates for actions
Reads are unprivileged: which tools are installed and which the repositories offer are local database queries any user may make. Escalation is sudo -n, which never prompts, and covers only the installs, updates, removals and the repository setup you confirmed.
✓
No daemon, no state of its own
Nothing keeps running after you quit, and nothing is installed to run later. The system is the source of truth; the tool re-reads it after every change.
✕
Opens network connections
It fetches https://tui.tools/catalog.json, the list of tools and their versions. The catalog only informs: nothing from it reaches a command line except a name matching tui-<word>, and the package manager verifies the signed repository. --offline uses the snapshot in the binary.
✓
Static binary
Released statically linked, with no runtime dependencies to install.
✓
Signed release, with provenance
checksums.txt carries a keyless cosign signature from this repository's release workflow, every archive has a CycloneDX SBOM, and every archive, package and the checksum file carry SLSA build provenance. The security page shows the three commands that check it.
Reporting
Report a security issue privately, through GitHub's private vulnerability reporting on the repository's Security tab. The family-wide policy, and what counts as in scope, is on the security page.
## tui-tools v0.2.1
tui-kit v0.3.0: the dialogs wrap and scroll instead of clipping the
command preview, and the picker filters as you type.
Built by this repository's CI on the tag itself. Each archive ships a
CycloneDX SBOM, `checksums.txt` carries a keyless cosign signature, and
every file has SLSA build provenance — see the README's "Verify a
download" for the two commands that check them.
The commits in this release:
## Changelog
* 5cffc85bf3773457fa40b6e4f7331e3e2c8d45b9 Bump tui-kit to v0.3.0 (#15)
* 541da53892282b130a36d7054a35bb443376c5e4 Re-render the README frames on the companions build (#14)
## tui-tools v0.2.0
v0.2.0
Built by this repository's CI on the tag itself. Each archive ships a
CycloneDX SBOM, `checksums.txt` carries a keyless cosign signature, and
every file has SLSA build provenance — see the README's "Verify a
download" for the two commands that check them.
The commits in this release:
## Changelog
* c25cd2e6a834404f6ae75e54d8a1c67fda22c9c2 A code of conduct that fits on one screen (#11)
* ed096cc3462b8ac4986bd8d172258b0870af400d Add --report, and a bug form that asks for it (#12)
* 65906d641b388bca2fadda50f23c65efea58ed45 Carry the OpenSSF Best Practices badge (#9)
* a5344ec3b5b5fad554ea98050ae8e558a3bde9fb Show the companions, and where each installed one came from (#13)
* bc4643d4471188e0c18a7f7180ac5ffa0eb2cb5a Take tui-kit v0.2.8: hashed pip install, provenance bundle on the release (#10)
## tui-tools v0.1.3
Release notes that say what changed
The release header now prints the whole tag message, so this paragraph is
the first release note a reader of the family sees on a release page.
Nothing in the launcher itself moved since v0.1.1: same dashboard, same
package, same epoch.
Built by this repository's CI on the tag itself. Each archive ships a
CycloneDX SBOM, `checksums.txt` carries a keyless cosign signature, and
every file has SLSA build provenance — see the README's "Verify a
download" for the two commands that check them.
The commits in this release:
## Changelog
* c10f83d71e7db96632ec951f8f8ab80638e9217d Print the whole tag message, not only its body (#8)
## tui-tools v0.1.2
Built by this repository's CI on the tag itself. Each archive ships a
CycloneDX SBOM, `checksums.txt` carries a keyless cosign signature, and
every file has SLSA build provenance — see the README's "Verify a
download" for the two commands that check them.
The commits in this release:
## Changelog
* bad69f56854ddf9a474cbc70528c11f22da96fb9 Fetch the tag annotation before releasing (#7)
* 5191fe142898ffde4020e838e47e2f59cae4920e Say beta once (#6)
## tui-tools v0.1.1
Built by this repository's CI on the tag itself. Each archive ships a
CycloneDX SBOM, `checksums.txt` carries a keyless cosign signature, and
every file has SLSA build provenance — see the README's "Verify a
download" for the two commands that check them.
The commits in this release:
## Changelog
* 9739acf69ba242bff964856368eb6ecf1e3fc07d Pin what CI runs, fuzz the parsers, and say the releases are signed (#4)
## Changelog
* 22ef3093debdf59d9e3be1f96ed0d5a40c812978 Initial commit
* c6fe870df208bf0145a417b5616b68269814b0dc Outrank the metapackage that used to carry this name (#3)
* 43ce7c9482beb181af6d0b7e3d48f1ad3c170587 Take tui-kit v0.2.7: an Arch install is one -Syu step (#2)
* e4955cd15ae8779c798e684202cf18791d923079 The launcher: every tool of the family in one dashboard (#1)
