The PATH variable is wrong or missing the directory
What's actually happening here is that your shell can't find the executable because it's not in any of the directories listed in the PATH environment variable. This is the most common cause, and it's almost always fixable in under a minute.
First, confirm it's a PATH issue by checking if the command exists elsewhere. If you're trying to run ffmpeg, try:
which ffmpeg
find /usr -name ffmpeg 2>/dev/null
If the find command shows a file like /usr/local/bin/ffmpeg, then the fix is to add that directory to your PATH. The reason step 3 works is that the shell reads PATH left to right and stops at the first match. So you want the directory that has your binary to be in there.
To fix it for your current session:
export PATH="/usr/local/bin:$PATH"
To make it permanent, add that line to your ~/.bashrc or ~/.zshrc depending on your shell. Then run source ~/.bashrc or just open a new terminal.
But wait — sometimes PATH gets clobbered by a bad line in your startup files. If you ever see command not found for basic commands like ls or cat, that's a strong signal your PATH is broken. Check it with:
echo $PATH
If it's empty or missing /usr/bin and /bin, you need to fix it fast. You can run commands by their full path, like /bin/ls, to get back to a working state, then edit your startup file.
The package isn't installed
Sometimes the command genuinely doesn't exist because the software was never installed. This happens more often than you'd think, especially on minimal server installs. The error message gives no hint, so you have to figure it out yourself.
For example, on a fresh Ubuntu server, htop won't be there. The fix is straightforward:
sudo apt update && sudo apt install htop
On RHEL/CentOS/Rocky it's sudo dnf install htop, and on Arch it's sudo pacman -S htop. The key is knowing your package manager.
Here's a table of common commands and which package provides them:
| Command | Package (Debian/Ubuntu) | Package (RHEL/Fedora) |
|---|---|---|
| htop | htop | htop |
| ifconfig | net-tools | net-tools |
| dig | dnsutils | bind-utils |
| tree | tree | tree |
If you're not sure which package provides a command on Debian/Ubuntu, use apt-file search after installing apt-file. On Red Hat-based systems, dnf provides /usr/bin/command does the same trick.
One gotcha: sometimes the command is in a package that's installed but not in your PATH because it's in /usr/sbin and your user isn't root. Tools like ifconfig and route live there. If you're not root, you'll see "command not found" even though the package is fine. The fix is to use the full path or become root with sudo.
Shell builtins and the hash table
This one's subtle and catches people off guard. Your shell remembers where it found commands in a hash table. If you install a new version of a program after the shell already looked up the old one, the shell might still be pointing to the old location — or worse, the old location got deleted and now the command is "not found" even though the new one exists.
I've hit this after compiling something from source into /usr/local/bin while an older version sat in /usr/bin. The shell cached the old path. The fix:
hash -r
That clears the entire hash table. Or if you want to forget just one command:
hash -d ffmpeg
The reason this happens is that bash and zsh cache command locations for speed. Normally you don't notice because the cache stays valid. But when you move or delete binaries, the cache goes stale.
Also, watch out for shell aliases that shadow commands. If you alias git to something that no longer exists, you'll get "command not found" even though git is installed. Check with type git — it will show you whether it's an alias, a builtin, or a file on disk.
Quick-reference summary
| Cause | Symptom | Fix |
|---|---|---|
| PATH missing directory | Command exists but not in PATH | Add directory to PATH in ~/.bashrc |
| Package not installed | Command not found even on fresh install | Install package with apt/dnf/pacman |
| Hash table stale | Command worked before, fails after install/removal | Run hash -r |
| sbin not in PATH for non-root | Command exists but only for root | Use full path or sudo |
Most of the time you'll fix this in seconds. If you've checked all the above and still stuck, try strace -f -e execve yourcommand to see what the shell is actually trying to execute — that'll reveal the real path it's looking for.
Remember, the shell is just a program. It doesn't magically know where anything is. It follows PATH, consults its hash table, and if nothing matches, it gives up. Your job is to either put the command where the shell expects it, or tell the shell where to look.