Fix 'bash: command not found' on Linux (PATH fix)

Quick answer (for advanced users)

Run export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin in your terminal. Add that same line to your ~/.bashrc (or ~/.zshrc if you use Zsh) so it persists.

Why this happens

I know this error is infuriating — especially when you know you installed something. You type ls, grep, or even python3, and bash just shrugs. The root cause is almost always a broken PATH environment variable.

Your shell uses PATH as a list of directories to search for commands, separated by colons. When you accidentally export a bad PATH (like PATH=/some/nonsense), or a script corrupts it, bash can't find anything — even basic system commands like sudo or cd. This happens a lot when you're messing with custom installs, Python virtual envs, or Docker environments. On Ubuntu 22.04, I've seen it after a broken Ansible playbook. On CentOS 7, a misconfigured /etc/profile.d/ script triggers it.

Step-by-step fix

Check your current PATH
Run echo $PATH. If you see something like /usr/local/bin:/usr/bin or less, that's the problem. A healthy path includes /usr/local/sbin, /usr/sbin, /sbin, and /bin. If you see only one directory, you've found the culprit.
Reset PATH temporarily
Type this exact command (copy-paste it to avoid typos):
```
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
```
Now try ls or which ls. It should work. This fix lasts only for the current terminal session.
Make it permanent
Open your shell config file. For Bash: nano ~/.bashrc. For Zsh: nano ~/.zshrc. Add the same export line at the end. Save and exit, then run source ~/.bashrc or source ~/.zshrc. Test again in a new terminal window.
Restore system default PATH
If you still see issues, your ~/.bashrc might be overriding the system PATH. Look for a line like export PATH=something that doesn't include the standard directories. Comment it out by putting a # at the start, then source the file again.

Alternative fixes if the main one fails

Missing package
If only one command is missing (e.g., ifconfig but ls works), that command isn't installed. On Debian/Ubuntu: sudo apt update && sudo apt install net-tools. On RHEL/CentOS: sudo yum install net-tools (or dnf if you're on Fedora). I see this a lot with nslookup, dig, and curl.
Check /etc/profile or /etc/environment
If the fix resets every time you open a new shell, a system-wide config is corrupting PATH. Check /etc/profile and /etc/environment for bad export statements. On macOS (which also uses bash), it's often /etc/paths.
Use full path to the command
For a one-off, you can run commands by their absolute path: /usr/bin/apt or /bin/systemctl. This skips PATH entirely.
Reinstall bash-completion or shell
In rare cases, your shell installation itself is broken. On Ubuntu: sudo apt install --reinstall bash. This restores the default /etc/bash.bashrc.

Prevention tip

Never run export PATH=something without appending $PATH at the end. The correct way is export PATH=/new/dir:$PATH. This prepends your custom directory without wiping the rest. Also, before editing your shell config, take a backup: cp ~/.bashrc ~/.bashrc.backup. Trust me, this one habit has saved me hours over the years.

If you're using Docker or a CI environment, always check your PATH in the Dockerfile. A common mistake: ENV PATH=/opt/bin instead of ENV PATH=/opt/bin:$PATH. That'll break every subsequent RUN command.

Pro tip: If you export PATH and then lose sudo access, you can still run /usr/bin/sudo — the full path bypasses the shell's PATH lookup.