Fix 'bash: command not found' on Linux

Quick answer: Run echo $PATH to check your PATH variable. If it's empty or missing /usr/bin, /bin, or /usr/local/bin, export them: export PATH=/usr/bin:/bin:/usr/local/bin:$PATH. Then re-source your shell config.

I've been fixing Linux systems for small businesses for over a decade. This error comes up constantly. You type ls, grep, or even bash itself, and bash just grunts back: command not found. The worst part? It's almost never a broken system – just a broken environment. Last month alone, I had two clients panic because their web servers stopped responding to SSH after a botched package update. Both times, PATH was the culprit.

Here's the truth: bash finds commands by scanning the directories listed in your PATH environment variable. If that variable gets corrupted, or if a command's directory isn't included, you get that error. Most people blame missing packages, but nine times out of ten, it's PATH.

Step-by-Step Fix

Check your current PATH
Run echo $PATH. If it's blank, or missing /usr/bin, /bin, /usr/local/bin, or /sbin (for root), you've found the problem.
Set PATH temporarily
For immediate access, run:
```
export PATH=/usr/bin:/bin:/usr/local/bin:/sbin:$PATH
```
Now try ls. If it works, the issue is in your shell config.
Fix your shell config permanently
Open ~/.bashrc (or ~/.bash_profile for login shells). Look for the line that sets PATH. It should look like:
```
export PATH=$PATH:/some/other/dir
```
If something is overwriting PATH with a wrong value, comment that line out and add the default back:
```
export PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
```
Then source it: source ~/.bashrc.
Check if the command is actually installed
If PATH looks correct, run which commandname. If it returns nothing, the command isn't installed. Install it with your package manager – apt install commandname, yum install commandname, or dnf install commandname. For common commands like ifconfig, it's often net-tools.
Use absolute path as a workaround
If you know the command is installed but bash can't find it, try the full path: /usr/sbin/ifconfig. If that works, you know PATH is still wrong.

When the Main Fix Doesn't Work

If PATH is correct and the command is installed, you might have a shell compatibility issue. Some scripts or installations require a specific shell. Run echo $SHELL – if it says /bin/sh and the command is a bash-specific script, switch to bash: bash. Then retry.

Another common gotcha: broken symlinks. Run type commandname – if it says something like commandname is hashed (/usr/bin/commandname) but the file doesn't exist, remove the hash: hash -d commandname. Then try again.

If you're on a minimal Docker container or a stripped-down CentOS install, sometimes /bin is a symlink to /usr/bin, and that symlink got broken. Check with ls -l /bin. If it's a broken link, recreate it: ln -sf /usr/bin /bin.

Prevention Tip

The easiest way to prevent this: never edit ~/.bashrc or ~/.bash_profile without backing it up first. I use cp ~/.bashrc ~/.bashrc.backup before any change. Also, when installing packages from third-party repos (like NodeSource or EPEL), test with echo $PATH after the install. Those scripts sometimes mess with PATH. One client had a faulty NodeSource installer that set PATH to /opt/node/bin and nothing else. Took me ten minutes to trace.

Finally, if you use sudo, remember that sudo resets PATH to a secure default. That's why sudo commandname might fail while commandname works. If you need sudo to use your PATH, run sudo -E commandname or edit /etc/sudoers to include Defaults exempt_group=admin if it's a group issue. But that's a bigger topic for another day.

Real story: Had a client last month whose entire print queue died because of this. Their backup script ran as root but had a malformed .bashrc that stripped PATH to just one directory. The script failed for three days before they called me. Fixed in two minutes: added the default directories back to PATH in /root/.bashrc and sourced it. Don't let this be you.