superfile: the binary is spf, and half the install is a piped script

The project is superfile and the command you type is spf

The repository is superfile, the module is github.com/yorukot/superfile, and the command is two characters shorter. Building from source makes the rename visible at the last step.

git clone https://github.com/yorukot/superfile.git --depth=1

cd superfile

./build.sh

On macOS and Linux the build lands a binary called spf inside the repository, and the README tells you to move that file into your PATH yourself, which means a root-owned write into /usr/local/bin rather than something a package manager handled for you. Windows takes a different route.

go build -o bin/spf.exe

There you compile directly and then edit your system environment variables to add the repository's bin directory to PATH. Either way the program you launch afterwards is the same one.

spf

Scripts and documentation that assume the name superfile will be wrong, and that is the sort of thing worth checking before you write an alias or a wrapper.

Two of the four install paths pipe a script straight into your shell

Four routes are documented, and two of them execute code you have not read.

bash -c "$(curl -sLo- https://superfile.dev/install.sh)"

powershell -ExecutionPolicy Bypass -Command "Invoke-Expression ((New-Object System.Net.WebClient).DownloadString('https://superfile.dev/install.ps1'))"

The PowerShell line is worth reading twice, because it pairs ExecutionPolicy Bypass with Invoke-Expression, which means the downloaded string runs with policy checks switched off for that invocation. The README does address this directly, linking install.sh and install.ps1 under website/public so you can read what will execute before you execute it. That is a better answer than most projects give, and it is still a remote script.

The two package managers take a different risk profile.

winget install --id yorukot.superfile

scoop install superfile

For a machine you do not own, or one with an audit requirement, the winget and scoop identifiers are the parts you can review and pin, which the curl path does not give you.

The update check calls GitHub once a day, and one config key stops it

superfile checks for a newer release on its own. The stated behaviour is that it fetches the latest released version from GitHub, does so only if the last version check was less than 24 hours ago, and prints a prompt to the user when a newer version is available.

That is a startup-time network call to github.com in a tool you opened to look at files. The README gives you exactly one documented control over it, setting auto_check_update to false in superfile config, and points at the config wiki for the surrounding keys.

Two things the README does not answer: whether the check blocks the interface while it runs, and what happens when GitHub is unreachable. On a locked-down or air-gapped host those are the only two questions that matter, and you will have to answer them by running the binary rather than by reading the page. Uninstalling has the same shape as installing, with uninstall.sh and uninstall.ps1 fetched from the same host.

go 1.26 in go.mod, and make runs the whole workflow

Building from source has one hard requirement and one surprise. The requirement is in go.mod, which declares go 1.26, so a machine on an older Go toolchain will not build this tree.

The surprise is that make is not build. The default target is all, which runs dev, which executes ./dev.sh.

test:
	@go test ./...

# Run linter
lint:
	@golangci-lint run

Run build instead and you get ./dev.sh --skip-tests. Run testsuite and you get ./dev.sh --testsuite, the recorded-terminal suite that lives in testsuite/ and vhs/. Plain make, in other words, does more than compile, so anyone expecting a quick build on a machine without golangci-lint will hit the checks first. There is a notice target that runs go run ./scripts/generate_notice.go and produces NOTICE.md from notice.tmpl, so the dependency attribution file is generated rather than maintained by hand.

The dependency list names the exiftool, zoxide and archive paths

go.mod is a better description of what the program touches than any feature list would be. The TUI itself comes from the Charm stack, bubbletea, bubbles and lipgloss, with termenv and ultraviolet handling terminal capability detection.

Then come the parts that reach outside the process. barasher/go-exiftool is the Go binding for the exiftool program, so reading archive metadata depends on an external binary that the Go module does not install, and the README never states an exiftool prerequisite. lazysegtree/go-zoxide is the jump-to-directory integration, written by the same handle the README lists as the second core maintainer. reinhrst/fzf-lib handles fuzzy selection, alecthomas/chroma handles syntax colouring, and golift.io/xtractr pulls in iso9660, cpio, rpm and flac, which is how archive and media extraction stays inside one dependency.

The pattern for a reader: several features shell out or link native helpers that no README line promises, so the first run on a minimal image is where you find out which ones are missing.

cd_on_quit is the shell glue, and the quick start never mentions it

A top-level directory called cd_on_quit describes the feature that makes a terminal file manager worth keeping: the shell returns to the directory you were browsing when you quit. It is integration you add to your shell profile, and because it is a shell detail rather than a program flag it does not appear anywhere in the installation section of the README, which stops at spf and sends you to the tutorial page for how to use the thing.

The repository also carries flake.nix, flake.lock and gomod2nix.toml for a Nix build, an .envrc for direnv, and .golangci.yaml for the linter the Makefile calls. So there are three distinct build paths beyond the two install scripts: the documented build.sh, a hand-run go build, and a Nix flake, each producing the same spf.

One README warning is worth repeating for anyone arriving from vim. The hotkeys section says that if you are a vim or nvim user you should change the default hotkeys config to the vim version, which means the keybindings you get out of the box are not the ones you will use everywhere else.

Windows is on the supported list with a note attached

The supported systems list ticks Linux and macOS, and lists Windows with the parenthesis not fully supported yet. That is the project's own word for it, on the same page as the four install routes, and it sits next to the two shell installers that exist only because Windows needs them.

The releases move steadily underneath that: v1.5.0 on 2026-01-13, v1.6.0-rc1 on 2026-05-27, and v1.6.0 on 2026-06-07, with the repository not archived and the last push on 2026-09-30. The gap between the last tagged release and that push is worth noticing, because it means the tag line and the development line are not the same thing, and a release-candidate tag sitting in the same list is a reminder to check which artefact you actually installed.

Licensing is unremarkable and helpful here: MIT, with LICENSE at the root and the generated NOTICE.md crediting the open-source licences that JetBrains provides to maintainers. That notice file exists because the TUI stack comes from Charm, and the project chose to publish the attribution automatically rather than leave it in a README paragraph.

Where superfile sits against a two-pane file manager

The comparison people search for is usually against a two-pane manager, and the repository makes no comparison at all. No alternative is named anywhere in it, so the difference in approach has to be described rather than measured.

A two-pane file manager presents two directory columns side by side and drives everything from a key-driven command line, with panels as the primary object. superfile takes the full-screen route: it is a Bubble Tea program with one main view, a preview pane, plugins gathered from a plugin wiki, themes configured as files, and hotkeys drawn from a configurable wiki page. Configuration is therefore a set of files you edit and a plugin set you install, not a menu tree you navigate.

Neither README nor go.mod gives you a figure for deciding which is faster or lighter, so this is a shape difference, not a verdict. If your work depends on two panels visible at once, or on a shell that drops you into the browsed directory with no profile edit, check those two behaviours yourself before switching.

Editorial conclusion

superfile fits a terminal-first workstation that wants a full-screen file manager with plugins, themes and a change-directory-on-quit integration, and that is used to installing things by hand. It does not fit a fleet that requires a signed package or a host with no outbound network, because the default install is a piped script and the update check calls GitHub at startup. Verify first what your platform produces: the macOS and Linux build ends with a binary named spf, the Windows build produces spf.exe, and the README marks Windows as not fully supported yet.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes