Fix 'bash: command not found' on Linux in 2 Minutes

Yep, This Error Sucks

You open your terminal, type ls, and get slapped with bash: ls: command not found. Or worse, sudo stops working. I’ve been there — it’s panic-inducing, especially when you’re in the middle of something critical. But here’s the good news: it’s almost always a broken PATH variable, and the fix is dead simple.

The Fix: Restore Your PATH

Run this in your terminal right now:

export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

That’s it. Your basic commands (ls, cd, sudo, grep) will work again instantly. This sets a clean, default PATH for your current session.

Now make it permanent so you don’t hit this again after rebooting. Add the same line to your ~/.bashrc file (or ~/.bash_profile if you’re on macOS):

echo 'export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' >> ~/.bashrc
source ~/.bashrc

If you’re using Zsh (common on newer Ubuntu or macOS), edit ~/.zshrc instead.

Why This Works

The PATH variable tells Bash where to look for executables. When it’s empty or missing critical directories (like /usr/bin), Bash can’t find any commands. This usually happens when:

• You accidentally ran export PATH= without specifying anything
• A script you sourced mangled your PATH
• You edited .bashrc and made a typo (I’ve done that more times than I’ll admit)
• You installed something (like Anaconda or a custom Python) that overwrote PATH

By resetting PATH to the system defaults, you’re giving Bash its map back. The directories I listed cover all standard Linux utilities — /usr/bin for most commands, /usr/local/bin for user-installed software, and /sbin for system administration tools like fdisk.

Less Common Variations

Sometimes the error shows up for a specific command but not others. Here’s what to check:

1. Only sudo fails

If sudo says command not found but other commands work, your secure_path is broken. Fix it with:

sudo visudo

Look for the line Defaults secure_path and make sure it includes /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin. Save and exit.

2. Python or pip fails

If you can’t run python3 or pip, but ls works, your PATH might be missing ~/.local/bin. Add it:

export PATH=$PATH:$HOME/.local/bin

Then add that to your .bashrc.

3. Flatpak or Snap apps not found

Those install to /var/lib/flatpak/exports/bin or /snap/bin. Add them:

export PATH=$PATH:/var/lib/flatpak/exports/bin:/snap/bin

4. Docker commands not found

Docker binaries live in /usr/bin/docker normally, but if you installed via Snap or from source, they could be elsewhere. Check which docker after fixing PATH.

How to Prevent This

• Don’t set an empty PATH — never run export PATH= without appending something. Always use export PATH=$PATH:/new/dir.
• Back up your .bashrc before editing it. One typo can break everything. Use cp ~/.bashrc ~/.bashrc.backup.
• Test changes in a new terminal — after editing .bashrc, open a new terminal window and run echo $PATH to verify it looks right.
• Use source cautiously — if you source a script from an untrusted source, it can overwrite your PATH. Check the script first with cat script.sh | head -20.

That’s it. You’ve got your terminal back, and you know how to lock it down so this doesn’t happen again. Go finish whatever you were working on.