Install lnav with Homebrew, apk, apt, dnf, MacPorts, Nix, pacman, zypper, scoop, winget

Project links

• Homepage
• Repository
• Upstream docs
• Package manager page

Commands and aliases

• lnav

Project history

The upstream GitHub repository was created in September 2009 and remains maintained by Tim Stack under the tstack/lnav project. The README presents lnav as a source repository backed by lnav.org and the Read the Docs manual, with static binaries and package-manager installation as first-class distribution channels.

Over time lnav accumulated features that moved it beyond a simple viewer: automatic decompression, format detection, chronological merge across files, follow mode for files and directories, JSON-lines pretty-printing, regex and SQLite filtering, and a SQL prompt over indexed log data. The official docs describe separate UI, command, SQLite, log-format, session, and performance sections, reflecting that growth.

Adoption history

lnav has become a familiar package in Unix-like developer and operations environments because it solves a common local debugging problem without requiring a server, web UI, or log aggregation stack. The GitHub repository shows broad interest for a terminal utility, and the input package facts show distribution across Homebrew, Debian, Fedora, Nix, MacPorts, pacman, Scoop, winget, and other package managers.

The project also maintained an approachable adoption path: lnav.org offers a high-level overview and an SSH playground, while the README documents Homebrew, FreeBSD, static release binaries, and source builds. That combination made it easy for developers to try lnav during incident debugging or local log exploration.

How it is used

Typical use is to point lnav at log files or directories and let it identify, collate, and index messages. The documentation says files can be passed on the command line or opened later, directories can be monitored, archives can be extracted when libarchive support is available, and piped input can be captured.

Inside the TUI, users navigate like a pager, jump between errors, search and highlight with regular expressions, filter with expressions, inspect histograms, and run SQL queries against parsed log data. It is also commonly used with systemd by piping journalctl output into lnav.

Why package nerds care

lnav is significant because it is a single CLI package that absorbs a surprising amount of operational log-analysis workflow. It gives package-manager users an immediate local alternative to stitching together tail, grep, awk, less, jq, and ad hoc scripts.

For maintainers, lnav is interesting because it packages a real TUI application with many native dependencies, including SQLite, PCRE2, libarchive, compression libraries, and terminal handling. Its availability across Unix package sets and Windows package managers reflects demand for local-first log analysis.

Timeline

• 2009: The tstack/lnav GitHub repository is created.
• 2010s: lnav grows from a terminal log viewer into a log-analysis TUI with format detection and SQL support.
• 2020s: The project documents releases through GitHub, publishes static binaries, and maintains Read the Docs documentation.
• 2026: The repository shows v0.14.x releases and continued development.

Related projects

• tail, grep, less, and journalctl are common adjacent tools in the workflows lnav replaces or complements.
• SQLite is central to lnav's analysis model because lnav exposes parsed log data through SQL.
• Angle-grinder is named by the lnav README as another command-line log slicing and analysis tool.

Sources

• https://api.github.com/repos/tstack/lnav
• https://docs.lnav.org/en/latest/formats.html
• https://docs.lnav.org/en/latest/usage.html
• https://github.com/tstack/lnav
• https://lnav.org/
• source_facts.package-manager