5 CLI Tools I Use to Keep Terminal Workflows Less Annoying

The terminal is supposed to make work faster, which is funny, because mine regularly turns into a junk drawer with a cursor. Old commands hide in history, aliases multiply quietly, and somehow I still end up searching the web for the same tar, find, grep, or Git command I already solved months ago.

This is not a “definitive best CLI tools ever created by humanity” list. Those lists usually become 47 tools you install, admire, and forget. These are five CLI tools I actually reach for when I want terminal work to feel less annoying across zsh, bash, macOS, and Linux.

The Small Problem With Terminal Productivity

Terminal workflows rarely collapse because of one dramatic failure. They usually decay through tiny repeated annoyances.

You forget the exact command. You remember an alias, but not what it does. You know a file exists somewhere, but not where. You open a config file and immediately wish it had syntax highlighting. You run ls and get a gray wall of filenames that technically contains information, in the same way a landfill technically contains furniture.

Good CLI tools do not need to replace your whole workflow. The useful ones shave off friction. They make the thing you already do slightly faster, clearer, or harder to mess up.

My go-to 5 CLI tools are:

1. gloss — a command glossary for reusable shell commands
2. fzf — fuzzy finding for almost everything
3. ripgrep — fast text search
4. bat — readable file viewing
5. eza — a better ls for daily navigation

There are plenty of honorable mentions: zoxide, fd, jq, httpie, tmux, delta, lazygit, just, tldr, pet, navi, direnv, starship, and half the Rust-powered replacements for old Unix commands. I like many of them. But if the goal is fewer annoying terminal moments, these five cover a practical loop: remember, find, search, inspect, and navigate.

1. ⭐ Gloss — A Command Glossary for Reusable Shell Commands

Let’s start with the biased one. I built gloss because I kept re-searching the same shell commands and spreading aliases across history, notes, random Markdown files, and shell config files.

At some point, shell history stops being useful memory and becomes a messy archaeological site. Yes, the command is probably in there. Somewhere. Under six failed attempts, three typos, and one questionable sudo experiment.

gloss gives reusable commands a small local home. You can save a command with a description and tags, search it in a TUI, scan zsh or bash config files, and sync selected aliases into one managed shell config block with backups.

That last part matters. I do not want a tool spraying aliases all over .zshrc or .bashrc like it has been left unsupervised with a paint roller. gloss writes only inside a dedicated managed block:

# >>> gloss aliases >>>
alias gs="git status"
alias ll="ls -lah"
# <<< gloss aliases <<<

It is not meant to replace every dotfiles setup. A plain text file piped into fzf is a perfectly valid solution. Something like this can go a long way:

git status # check current repo state git
tar -czf archive.tar.gz folder # create compressed archive tar gzip
curl -I https://example.com # inspect headers curl http

Then you can pipe it into fzf, select a line, and build your own little workflow. Honestly, that is the final boss of many developer tools: “could be a text file and fzf.”

gloss is for the point where I wanted more structure without turning it into a huge knowledge base. Descriptions, tags, TUI browsing, scan/import from zsh and bash, and safer alias sync were enough.

Best for:

• people with lots of reusable shell commands
• people who forget what their aliases do
• people who want a local command glossary close to the terminal
• people who like TUIs but do not want a huge app

Not for:

• people happy with shell history alone
• people who already have a clean text file + fzf setup
• people who do not want any tool touching shell config files, even with preview/backups

Useful links:

• gloss on GitHub
• gloss landing page

2. fzf — Fuzzy Finding for Almost Everything

Once commands are saved somewhere, the next problem is finding things fast. That is where fzf earns its reputation.

fzf is a general-purpose fuzzy finder. That sounds boring until it becomes the thing quietly powering half your terminal. Files, command history, processes, Git branches, directories, snippets — if you can pipe a list into it, fzf can help you choose from that list without typing the exact thing.

The classic use case is command history search. Instead of pressing the up arrow like you are trying to win the saddest slot machine, you fuzzy-search your previous commands.

history | fzf

Most shell integrations go further and bind this to Ctrl+R, which makes old command lookup feel less like memory work and more like search.

I also like fzf for file selection:

vim "$(find . -type f | fzf)"

That example is intentionally basic. In practice, you might combine fzf with fd, ripgrep, bat, Git, or custom scripts. Some setups use previews, so you can move through search results and see file contents before selecting anything.

A simple preview example:

fzf --preview 'bat --style=numbers --color=always {}'

That is where fzf starts feeling less like a small filter and more like a terminal interaction layer.

I use it for:

• finding old commands
• jumping to files
• selecting Git branches
• choosing scripts
• narrowing down noisy output
• building tiny one-off terminal menus

The nice thing is that fzf does not ask you to change your whole terminal life. It slips into existing commands. It is duct tape, but premium duct tape — the kind that fixes the workflow and somehow makes it look intentional.

3. ripgrep — Fast Text Search Without the Usual Pain

After finding files, I usually need to search inside them. For that, ripgrep, usually called rg, is my default.

The simple pitch: it is like grep, but fast, practical, and less interested in punishing you for having a modern project folder.

rg "DATABASE_URL"

That searches recursively, prints useful matches, and by default respects .gitignore. This is one of those defaults that sounds small but saves real irritation. Most of the time, I do not want search results from node_modules, build directories, generated files, vendor folders, or whatever digital compost heap lives in a project.

For source code, config files, notes, and scripts, rg is usually the first thing I reach for.

A few examples:

rg "alias " ~/.zshrc ~/.bashrc ~/.bash_aliases

rg "TODO|FIXME" .

rg --type go "func main"

rg --hidden --glob '!node_modules' "API_KEY"

The --type filtering is especially useful. Search only Go files, Python files, Markdown files, JSON files, and so on. It reduces noise without making you write a tiny shell spell every time.

How I use it with gloss is simple: when I find a command or pattern I keep searching for repeatedly, that is usually a sign it belongs in the glossary. rg helps me discover the thing; gloss helps me remember why I cared.

That separation is useful. Search tools are excellent at discovery. They are not always great at turning discoveries into reusable knowledge.

4. bat — A Less Miserable Way to Read Files

There is nothing wrong with cat. It does exactly what it says. It throws file contents into your terminal and then calmly walks away from the scene.

But for reading code, scripts, configs, Markdown, YAML, JSON, or anything where your eyes are expected to survive the experience, bat is much nicer.

bat is often described as a better cat: syntax highlighting, line numbers, Git integration, automatic paging for long files, and generally more readable output.

bat ~/.zshrc

bat README.md

bat package.json

It is not a complicated tool, which is part of the appeal. You can use it directly, or you can pair it with fzf as a previewer:

fzf --preview 'bat --color=always --style=numbers {}'

That combo is excellent. fzf lets you choose; bat lets you preview without opening each file. It is the difference between rummaging through a drawer with the lights off and having labels on the boxes.

I especially like bat for:

• previewing shell scripts before running/editing them
• reading config files
• checking Markdown
• inspecting JSON/YAML quickly
• making fzf previews more useful

Some people alias cat to bat. I do not always do that, because I still like plain cat for scripts and pipes where predictable minimal output matters. But for human reading, bat wins almost every time.

5. eza — A Better ls for Daily Navigation

The last tool is less dramatic, but it improves one of the most common terminal actions: looking around.

eza is a modern replacement for ls. It is the community-maintained successor to exa, and it gives you colorized output, icons if you want them, Git status, better long listings, and tree views.

A few common commands:

eza

eza -la

eza --tree --level=2

eza -la --git

The Git status view is useful in project folders. You can see what changed without immediately jumping into git status, and the tree output is handy when you need a quick mental map of a project.

I do not think eza changes your life. That would be an alarming amount of emotional pressure to put on a file listing tool. But it does make directory inspection clearer, and that matters because navigation is constant background noise in terminal work.

There is also lsd, which fills a similar role. Some people prefer its style. I lean toward eza, but both are worth trying. This is one of those choices where the “best” tool is the one whose output your brain reads fastest.

How These CLI Tools Fit Together

The real benefit is not in using each tool separately. It is in how they form a small workflow loop.

Here is a realistic version.

You start in a project folder and use eza to inspect the layout:

eza --tree --level=2

You use ripgrep to search for a config value, function, command, or old script:

rg "deploy"

You pipe files into fzf when the result list gets too long:

rg --files | fzf

You preview selected files with bat:

fzf --preview 'bat --color=always --style=numbers {}'

And this is where gloss fits into the loop. When a command keeps coming back — maybe a deployment command, Docker cleanup command, local server shortcut, curl header check, or some deeply specific rg/find combo — I save it with a description and tags:

gloss add

Later, instead of searching history again or trying to remember which note file contains the command, I hit gloss list or open the TUI:

gloss

Or I scan existing shell config files and import useful aliases/functions I already had lying around:

gloss scan

That is the whole point. Do not collect CLI tools like decorative mugs. Build a loop where each tool removes one small annoyance.

For me, the loop looks like this:

• eza helps me see where I am
• rg helps me find what I need
• fzf helps me choose from noisy output
• bat helps me read before acting
• gloss helps me keep those commands within reach

It is not fancy. It is just less irritating.

A Few Honorable Mentions

There are other CLI tools worth keeping nearby, depending on the work.

zoxide is a smarter cd that learns where you go and lets you jump around by partial names. It is one of those tools that feels weird for a day and then makes normal cd feel like walking to another city.

fd is a friendlier, faster alternative to find, with sensible defaults and clean output.

jq is essential if JSON appears in your life, willingly or otherwise.

httpie is easier to read than curl when testing APIs manually.

delta makes Git diffs easier to inspect.

tmux is still hard to beat when you need persistent terminal sessions, panes, and project workspaces.

tldr is perfect when man pages are too detailed and you only need the common examples.

pet and navi are especially relevant if you like command snippets and interactive cheatsheets. They overlap with parts of the problem gloss touches, though each tool approaches it differently.

Final Thoughts

You do not need every tool on this list. In fact, installing too many CLI tools at once is how a clean terminal turns into a garage where every shelf contains “useful stuff” nobody can identify.

Start with one annoying workflow.

If you constantly search old commands, try gloss or a plain text file with fzf. If file search is slow, try ripgrep. If opening files in the terminal hurts your eyes, try bat. If navigation feels muddy, try eza or zoxide.

The best CLI tools for productivity are not the ones with the longest feature lists. They are the ones that quietly remove friction from work you already do.

The terminal does not need to become your entire personality. It just needs to stop making simple things harder than they should be.

FAQ

• What are the best CLI tools for productivity?
  For a practical starting set, I would pick gloss, fzf, ripgrep, bat, and eza. Together they help with command recall, fuzzy selection, text search, file preview, and directory navigation.

• Do these tools work with both zsh and bash?
  Most of them work fine in both zsh and bash. Some shell integrations, shortcuts, or plugins may require shell-specific setup, but the core tools are generally cross-platform.

• Is gloss better than a text file with fzf?
  Not always. A text file with fzf is a great minimal setup. gloss is useful when you want more structure: descriptions, tags, TUI browsing, scan/import from shell configs, and managed alias sync with backups.

• Should I replace standard Unix tools like grep, cat, and ls?
  You do not have to replace them completely. I still think it is worth knowing the standard tools. But for daily local work, tools like ripgrep, bat, and eza often provide better defaults and clearer output.

• Which tool should I install first?
  Start with the annoyance you feel most often. If you lose commands, try gloss or fzf. If you search code constantly, try ripgrep. If you read files in the terminal, try bat. If directory listings feel noisy, try eza.

What is one small CLI tool that changed your daily workflow more than expected?