I have been running Linux as my daily driver for about twelve years. In that time I have collected a small drawer of tools that never make the front page of “top apps” roundups. Most of them are not famous. They do not get featured in distro repositories. They are the kind of things a friend tells you about over a beer, and you wonder how you lived without them for so long. None of them are going to change your life. Several of them have been quietly useful to me for years, and that is enough.
This is not a roundup of the same ten tools you see in every other Linux listicle. You already know about htop, tmux, and ripgrep. I am not going to tell you to install fzf (a fuzzy file finder that filters as you type) for the hundredth time, even though you probably should. The point of this article is to surface the things that I genuinely reach for, that I cannot easily find when I look for them, and that the mainstream press tends to skip.
fselect is a database query for your filesystem
Most of the time, when I want to find files, I reach for find. The syntax is ancient and the defaults are a little weird, but it works. The problem is that I do not always want to find files. I want to find files matching a SQL-like query. fselect is exactly that. It treats the filesystem as a table and lets you run SELECT, WHERE, and aggregate queries against it. Example:
fselect size, path from /home/ellann where size > 50m and name like '%log%'
This prints the size and path of every file over 50 MB whose name contains “log”, anywhere under /home/ellann. It is a tiny tool, written in Rust, and it has a man page that fits on one screen. The first time I ran it I had a small moment of recognition: this is what I have been trying to do with find and xargs for a decade. The query language is so much cleaner that I now reach for it daily.
A few patterns I have landed on:
fselect size, path from /home/ellann where size > 50m and name like '%log%'for finding space hogs.fselect count, mime from . group by mimeto see what kinds of files are eating my disk.fselect path from ~/Downloads where modified gt now() - 30dfor a clean “what did I download this month” list.fselect path from ~/projects where modified gt now() - 7d order by modifiedto see what I have been working on lately without greppinggit log.
The third one is the one I use the most. It replaces a script I used to keep in my dotfiles for years.
entr runs a command whenever a file changes
entr is a tiny C program with one job: run a command whenever a file changes. The classic use case is “rerun my tests when I save a file.” I use it for that, but I also use it for things I never expected. For example, I have a tiny Makefile that regenerates a static site, and I run it like this:
ls *.md | entr -c make
Every time I save a markdown file, the site rebuilds. The -c flag clears the screen between runs, so the output is not a mess. The same pattern works for regenerating diagrams, refreshing preview windows, and re-running linters.
A more obscure use: I run a small script that tails my ~/.ssh/known_hosts for any new entries. If you suspect that someone is SSHing into your box from a new IP, you can use entr to alert you the moment a new fingerprint appears. I am not going to pretend this is a security feature you should rely on, but it has caught a couple of issues in my homelab over the years.
The tool is twenty years old, it has zero dependencies, and it does exactly one thing. The man page is one page long. It is, in a way, the Platonic ideal of a Unix tool.
ripgrep-all searches inside binary files
ripgrep (usually invoked as rg) is well-known. ripgrep-all is its less-known sibling that adds the ability to grep inside PDFs, Office documents, EBooks, and zip files. The setup takes about thirty seconds:
cargo install ripgrep_all
Once installed, you can run rga 'postgres connection limit' and it will search inside the PDF of a PostgreSQL book, the EPUB of a Rust guide, and the zip of a project you downloaded last month. The first time I tried it I expected it to be slow. It is not. It indexes the documents on the fly and the results appear almost instantly.
The use case that sold me: I have a folder of conference talk slides in PDF. Whenever I want to remember what someone said about, say, “optimistic concurrency control,” I run rga 'optimistic concurrency' against the folder and I get the relevant slides back in under a second. It is the kind of tool you do not think you need until you have it, and then you cannot imagine going back.
The downsides are real. The dependencies are not trivial (it pulls in Poppler, the Rust regex engine, and a few other things). On a minimal Alpine install, getting it working takes about ten minutes. For most desktops it is a one-liner. Decide based on your pain threshold.
btop is what htop wanted to be
htop is fine. It has been fine for twenty years. btop is what would happen if you redesigned htop from scratch with modern hardware in mind. It shows CPU, memory, disk, network, and processes in one screen. It has a clean theme system. It is GPU-accelerated, which sounds gimmicky until you watch a CPU graph render at 60 frames per second and then go back to htop.
The killer feature for me is the process tree view. htop has a tree view too, but btop‘s version is cleaner, lets you collapse subtrees, and shows resource usage per process in a column you can sort. When I am debugging a runaway service, I can see at a glance which child process is eating the CPU. The same view in htop requires a column toggle and a sort.
It also handles container-aware metrics out of the box. If you are running Docker (a tool that runs applications in isolated environments called containers) or Podman (a Docker alternative that does not require a background daemon), btop can show you per-container resource usage without any extra setup. I have been using it on every machine I touch for about three years now, and I have not gone back to htop once.
pueue queues long-running shell jobs
A small confession: I run my long shell jobs in the background with & and forget about them. Sometimes I have six builds running at once and my laptop sounds like a hairdryer. pueue is the answer to that. It is a task queue for the shell. You submit jobs to it, and it runs them in order (or in parallel, up to a limit you set), and you can pause, resume, and reorder them interactively.
The killer feature is the persistence. Jobs survive reboots. If I am in the middle of a 4-hour dataset rebuild and I have to restart my laptop, I run pueue start and the job picks up where it left off. The same goes for overnight CI runs (Continuous Integration, a system that automatically builds and tests code on every change) on my homelab box: I submit them at 10 PM, the box reboots at 1 AM for an update, and pueue quietly resumes them.
The interface is a TUI (terminal user interface, an application that runs in your text terminal) that you launch with pueue. It feels like htop for jobs. You can see the queue, see the output of each job, and reorder things with keyboard shortcuts. There is a learning curve, but it is a one-hour curve. After that, you never go back to nohup and &.
Trade-offs
None of these tools are critical. You can live a full and productive Linux life without any of them. The trade-off for adopting any of them is the time you spend learning the syntax, the small amount of disk space, and the occasional dependency you have to pull in.
In my case, the math worked out because I touch the command line for a living. Your math will be different if you are a GUI-first user. Even then, two of these (btop and entr) are zero-setup: install them, they work.
ripgrep-all is the heaviest install by far. Pulling in Poppler and a Rust toolchain on a fresh box took me fifteen minutes. If you are on a constrained system, skip it and use plain rg for text and pdftotext for PDFs.
pueue is the one that has a real learning curve. Plan to spend an hour getting comfortable with it. The persistence and parallel-run features are not obvious from the docs.
If you are setting up a fresh Linux box and you only have time for one of these, install btop and move on. If you have a weekend to kill, install all six in order. You will be a slightly more dangerous Linux user by Sunday.
Bottom line
I am not going to tell you these tools are necessary. They are not. The point of the article is to surface things that have made my own Linux life quietly better, in case one of them makes yours better too. None of them are flashy. None of them are new. They are the kinds of tools that get better the longer you use them, and that is the kind of tool I want more of.