DEV Community: Valeriy Bagrintsev

Introducing Gloss: A Local-First Command Glossary for Your Terminal

Valeriy Bagrintsev — Thu, 07 May 2026 17:21:53 +0000

Introducing Gloss: A Local-First Command Glossary for Your Terminal

Shell history is useful. Until it becomes a pile of almost-right commands, forgotten flags, and aliases with names only past-you understood.

That was the itch behind Gloss.

Gloss is a small open-source CLI/TUI tool for saving reusable shell commands, searching them in a terminal UI, scanning zsh/bash configs, and safely syncing selected aliases into a managed shell config block.

It is built for people who keep re-searching the same commands and slowly turn .zshrc, .bashrc, notes, and shell history into one very specific junk drawer.

What Gloss Does

gloss gives reusable shell commands a small local home.

You can use it to:

save shell commands with descriptions and tags
browse and search commands in a terminal UI
scan zsh and bash config files for aliases/functions
import useful commands from existing shell files
add managed aliases
preview alias sync before writing anything
sync aliases into one dedicated shell config block
create backups when sync changes an existing shell file

The goal is not to replace your shell, your dotfiles, or your favorite fuzzy finder setup.

It is just a focused tool for one annoying workflow: keeping useful commands findable and reusable.

Why I Built It

I kept running into the same pattern.

I would search for a command, use it, forget it, then search for it again later. Sometimes I saved it as an alias. Sometimes I dropped it into notes. Sometimes I trusted shell history, which is optimistic behavior and should probably be monitored.

Eventually I had useful commands spread across:

shell history
.zshrc
.bashrc
random Markdown notes
aliases with unclear names
browser searches I had already done before

A plain text file with fzf can solve part of this. That is a good setup. gloss is for the point where I wanted a bit more structure: descriptions, tags, TUI browsing, scan/import, and safer alias sync.

How Alias Sync Works

Gloss does not rewrite your whole shell config.

Managed aliases are written inside one dedicated block:

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

Everything outside that block stays untouched.

Before syncing, you can preview what will be written. When sync changes an existing shell file, gloss creates a backup. If nothing changed, it does not rewrite the file just to feel productive.

That boring behavior is intentional.

Shell config files are not a playground.

Platform Support

Gloss currently supports:

macOS with zsh
Linux with bash

It is written in Go and stores data locally.
Windows is not officially supported yet.

Installation

Install script:

curl -fsSL https://raw.githubusercontent.com/Architeg/gloss/main/scripts/install.sh | bash

Homebrew:

brew install Architeg/tap/gloss

Then run:

gloss

Or check the version:

gloss version

What Gloss Is Not

Gloss is intentionally not:

a shell replacement
a package manager
a shell history analyzer
an AI command explainer
a full dotfiles manager
a cloud sync product

It is a small local utility for documenting, finding, importing, and safely syncing useful shell commands.

Feedback Welcome

Gloss is still new, so feedback is useful.

I am especially interested in thoughts around:

scan/import behavior
managed alias sync
TUI flow
whether the command glossary idea fits real terminal workflows
what would make it safer or simpler

If you already have a clean fzf + notes setup, I am also curious where Gloss feels unnecessary. That is useful feedback too.

5 CLI Tools I Use to Keep Terminal Workflows Less Annoying

Valeriy Bagrintsev — Thu, 07 May 2026 16:40:31 +0000

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:

gloss — a command glossary for reusable shell commands
fzf — fuzzy finding for almost everything
ripgrep — fast text search
bat — readable file viewing
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:

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?

How to Manage Shell Commands Without Turning zsh or bash Into a Junk Drawer

Valeriy Bagrintsev — Thu, 07 May 2026 15:09:03 +0000

How to Manage Shell Commands Without Turning zsh or bash Into a Junk Drawer

Shell history is great until it becomes a haunted attic. The command is probably there somewhere, wedged between three failed attempts, one typo, and a sudo moment that should not be legally discussed.

I built Gloss because I kept re-searching the same shell commands and spreading useful aliases across zsh, bash, notes, and random config files. This post is not really “use my tool, please clap.” It is more about the workflow problem that pushed me to build it — and the simple alternatives that are honestly good enough for many people.

The Problem: Shell History Is Not Knowledge

Shell history remembers what happened. It does not always remember why it mattered.

That difference becomes painful over time.

A command like this may be useful:

find . -name "*.log" -mtime +7 -delete

But when it appears in history later, it has no context. Was it safe? Was it for the current project? Did I test it first? Did I copy it from somewhere? Did it work, or was it one of the failed attempts before the actual command?

Shell history is chronological, not meaningful. It is a receipt drawer. Useful sometimes, but not exactly a knowledge system.

I still use history constantly. With tools like fzf, searching history becomes much nicer. Ctrl+R with fuzzy search is one of those tiny upgrades that makes the terminal feel less hostile.

But history has a ceiling. It is good for commands I recently used. It is weaker for commands I use once every few weeks, commands with dangerous flags, commands that need a note, or commands that belong to a specific category like Git, Docker, network checks, deployment, WordPress cleanup, or “things I should understand before pressing Enter.”

That is where I wanted something more deliberate.

Why Aliases Alone Become Messy

Aliases are the first obvious fix. And they are useful. Very useful.

alias gs="git status"
alias gp="git push"
alias ll="ls -lah"

A good alias turns a repeated command into muscle memory. One word instead of a small ceremony.

The problem starts when aliases become a private language nobody documented, including the person who wrote them. After enough time, .zshrc, .bashrc, or .bash_aliases can become a junk drawer with syntax highlighting.

You open the file and see:

alias dcu="docker compose up"
alias dcd="docker compose down"
alias fixperms="sudo chown -R $USER:$USER ."
alias thing2="some command I apparently trusted in 2024"

Very professional. Museum-quality chaos.

Aliases are fast, but they are not always self-explanatory. They also do not naturally answer questions like:

What does this alias do?
Why did I create it?
Is it still useful?
Is it safe?
Which project or workflow does it belong to?
Do I have five versions of the same idea?

For small sets of aliases, no problem. For years of terminal usage, things get weird.

Why Notes Are Too Far From the Terminal

The next solution is notes.

A Markdown file. Notion. Obsidian. Apple Notes. A private wiki. A giant commands.md file that starts clean and ends like a basement.

Notes are better than history because they can include explanations:

## Check HTTP headers

Use this when debugging redirects or CDN/cache behavior.

curl -I https://example.com

That is already much better. Context exists. The command is readable. Future-me has a fighting chance.

But notes have another problem: distance.

When I am in the terminal, switching to a browser or notes app often breaks the flow. It is not a huge interruption. It is just enough friction to make me not do it. And when friction wins, the command goes back into history, or worse, into a random alias with no explanation.

There are tools that bridge this gap. For example, QOwnNotes command-line snippet manager can search command snippets stored in notes using fzf or peco. That is a nice idea: keep notes as the source, but make snippets accessible from the command line.

I like that pattern. It proves the core need is real: commands need memory, search, and proximity to the terminal.

The Text File + fzf Solution

Before building anything, the obvious question is: why not just use a text file and fzf?

Honestly? That works.

You can create a simple file:

git status # check repo state git
curl -I https://example.com # inspect HTTP headers curl network
tar -czf archive.tar.gz folder # create compressed archive tar gzip
docker system prune -af # remove unused Docker data docker cleanup

Then search it:

cat commands.txt | fzf

Or make a tiny function:

cmds() {
  selected=$(cat "$HOME/.commands.txt" | fzf)
  printf '%s\n' "$selected"
}

That is already useful. It is simple, transparent, and easy to back up. Nobody needs a new app for every problem. Sometimes the correct architecture is “a file, a pipe, and a little self-control.”

There are also mature tools in this space. pet is a command-line snippet manager that lets you save, tag, search, and execute snippets. It can use fuzzy finders and has been around long enough to prove that command snippets are not a fake problem. navi approaches the idea from the interactive cheatsheet side, which is great when commands need parameters or guided input.

Those tools are worth checking out. They solve overlapping problems, and depending on your workflow, one of them may be the better fit.

So why did I still build gloss?

Because I wanted a particular shape of workflow.

Where I Wanted More Structure

The text-file version is elegant, but I wanted a bit more structure around my own command mess.

Not a full knowledge base. Not an AI command explainer. Not a shell replacement. Just a small local place where reusable shell commands can live with enough context to be useful later.

The missing pieces for me were:

descriptions that are separate from the command itself
tags for grouping commands by workflow
a TUI for browsing and editing without opening a separate notes app
scan/import from existing zsh and bash config files
managed alias sync with preview and backups
local storage, no account, no cloud requirement

That became Gloss.

Gloss is a small local-first CLI/TUI tool for reusable shell commands. It stores commands locally, lets me search them in a terminal UI, scans shell configs, and can sync selected aliases into one managed block.

The goal is not to make terminal work fancy. The goal is to stop re-solving the same small problems.

How Gloss Handles Commands

The basic Gloss workflow is simple.

Launch the TUI:

gloss

Or add an entry:

gloss add

An entry is just:

command
description
tags

For example:

curl -I https://example.com

Description:

Check HTTP response headers without downloading the body

Tags:

network, curl, debug

That sounds small, but this small bit of structure helps. A command stops being a mysterious line from the past and becomes a reusable note that still belongs in the terminal.

Gloss also supports direct commands:

gloss list
gloss list --tag git
gloss scan
gloss edit <command>
gloss delete <command>

The TUI is for browsing and editing. The CLI commands are for quick actions. Nothing revolutionary. That is partly the point.

How Scan and Import Help Clean Up zsh and bash

The part I personally needed most was scanning existing shell files.

Gloss can scan common shell config locations such as:

~/.zshrc
~/.bashrc
~/.bash_aliases

Run:

gloss scan

In the TUI, scan results can include aliases, simple functions, and executable scripts from configured paths. Then I can choose what to import.

This matters because most reusable commands already exist somewhere. They are just not organized. Some are aliases. Some are functions. Some are scripts. Some are ancient fossils from a setup you barely remember.

Importing them into a glossary does not force them to become aliases. It just makes them findable, readable, and editable. That is a safer first step than “rewrite my shell config, good luck everybody.”

How Managed Alias Sync Works

Alias sync is the dangerous part, so I wanted it boring.

Boring is good here.

Gloss does not rewrite the whole shell file. It writes aliases inside one managed block:

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

Everything outside that block stays untouched.

The flow is:

add a managed alias in Gloss
preview the sync block
sync when ready
Gloss writes or replaces only the managed block
backup is created only if an existing shell file actually changes

That backup behavior matters. Creating endless backups for no-op syncs would be annoying. Not creating backups when modifying shell files would be reckless. The middle ground is simple: backup when sync changes an existing file.

Example:

gloss alias add
gloss alias sync

This is mainly for people who want aliases, but do not want alias management to become a hand-edited swamp.

What I Intentionally Did Not Build

It is tempting to keep adding features. That is how a small command glossary becomes a life management platform with plugins, sync, AI summaries, a graph view, and probably a calendar for some reason.

I tried not to do that.

Gloss is not:

a shell replacement
a shell history analyzer
a package manager
an AI command generator
a full dotfiles manager
a cloud sync product
a replacement for fzf, pet, or navi

That last point is important. Gloss overlaps with snippet tools, but it does not try to win every category. A commands.txt file with fzf may be enough. pet may be better if you want snippet execution and mature snippet management. navi may be better if you want interactive cheatsheets with parameters.

Gloss is more narrowly about keeping reusable commands documented, searchable, importable from shell configs, and optionally syncable as managed aliases.

That is the lane.

A Practical Setup I Would Recommend

For a sane shell-command workflow, I would not start by installing five tools and reorganizing everything. That is how “productivity” becomes procrastination wearing a nice jacket.

I would start smaller:

Keep normal shell history.
Add fzf history search if you do not already use it.
Keep aliases for commands you run constantly.
Save less frequent but important commands somewhere searchable.
Use gloss, pet, navi, or a plain text file depending on how much structure you need.

A simple rule helps:

If I run it daily, it can be an alias.
If I need to understand it later, it needs a description.
If I keep searching it again, it belongs in a glossary/snippet system.
If it modifies shell config, it needs preview and backups.

That rule is not science. It is more like putting labels on boxes before the garage wins.

Installing Gloss

Gloss is open source under the MIT license, written in Go, and supports macOS/Linux with zsh and bash.

Install script:

curl -fsSL https://raw.githubusercontent.com/Architeg/gloss/main/scripts/install.sh | bash

Homebrew:

brew install Architeg/tap/gloss

Run:

gloss

Repo:
https://github.com/Architeg/gloss

Project page:
https://worksfine.dev/gloss/

Final Thoughts

Managing shell commands is not about becoming a terminal wizard. It is about not making the same tiny decisions forever.

Shell history is useful. Aliases are useful. Notes are useful. A text file with fzf is useful. But once commands start spreading across all of them, the workflow gets blurry. Gloss is my attempt to make that middle space cleaner: local, searchable, documented, and close to the terminal.

The terminal does not need another shiny layer of complexity. It needs fewer forgotten commands, fewer mystery aliases, and fewer browser searches for things already solved once. How do you manage the commands you know you will need again?

FAQ

What problem does Gloss solve?
Gloss helps manage reusable shell commands that are too important to leave buried in history but not used often enough to remember perfectly. It gives them descriptions, tags, search, scan/import, and optional managed alias sync.
Is Gloss better than using aliases in zsh or bash?
Not exactly. Aliases are still great for commands used constantly. Gloss is more useful for commands that need context, tags, or occasional lookup. It can also sync selected commands as aliases when that makes sense.
Can I just use a text file with fzf instead?
Yes. A text file plus fzf is a good minimal solution. Gloss is for users who want more structure: separate descriptions, tags, TUI editing, shell config scanning, and safer alias sync with backups.
Does Gloss replace tools like pet or navi?
No. pet is a mature command-line snippet manager, and navi is an interactive cheatsheet tool. gloss focuses on a local command glossary plus zsh/bash scan/import and managed alias syncing.
Is it safe to let a tool write to .zshrc or .bashrc?
Caution is reasonable. Gloss only writes inside a dedicated managed block, leaves unrelated shell config untouched, and creates backups when sync changes an existing shell file. Still, preview the block before syncing and keep your dotfiles backed up.

How do you manage reusable commands? Drop your setup, questions, or criticism in the comments — I’d like to see what works for other people.

DEV Community: Valeriy Bagrintsev

Introducing Gloss: A Local-First Command Glossary for Your Terminal

Introducing Gloss: A Local-First Command Glossary for Your Terminal

What Gloss Does

Why I Built It

How Alias Sync Works

Platform Support

Installation

What Gloss Is Not

Links

Feedback Welcome

5 CLI Tools I Use to Keep Terminal Workflows Less Annoying

5 CLI Tools I Use to Keep Terminal Workflows Less Annoying

The Small Problem With Terminal Productivity

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

2. fzf — Fuzzy Finding for Almost Everything

3. ripgrep — Fast Text Search Without the Usual Pain

4. bat — A Less Miserable Way to Read Files

5. eza — A Better ls for Daily Navigation

How These CLI Tools Fit Together

A Few Honorable Mentions

Final Thoughts

FAQ

How to Manage Shell Commands Without Turning zsh or bash Into a Junk Drawer

How to Manage Shell Commands Without Turning zsh or bash Into a Junk Drawer

The Problem: Shell History Is Not Knowledge

Why Aliases Alone Become Messy

Why Notes Are Too Far From the Terminal

The Text File + fzf Solution

Where I Wanted More Structure

How Gloss Handles Commands

How Scan and Import Help Clean Up zsh and bash

How Managed Alias Sync Works

What I Intentionally Did Not Build

A Practical Setup I Would Recommend

Installing Gloss

Final Thoughts

FAQ