Fix bash: command not found (PATH broken) in 3 steps

The 30-Second Fix: Reset Your PATH for This Session

What's actually happening here is that your shell can't find executables because the PATH variable got clobbered. The most common trigger: you edited .bashrc or .profile, made a typo like PATH=/some/dir instead of PATH=$PATH:/some/dir, and now every command fails.

First, don't panic. You don't need to reboot or reinstall. Just run this in your current terminal:

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

That resets PATH to the system defaults for this shell session. Test it with ls or which sudo. If it works, you're back in business. But this only fixes the current terminal. The next one you open will be broken again unless you fix the source.

One thing to watch: if export itself fails, your shell might be running with a weird environment. In that case, call the binary directly: /usr/bin/export PATH=... (yes, export is a builtin, so this won't work — instead use exec /bin/bash to start a fresh shell, then retry).

The 5-Minute Fix: Find and Edit the Broken File

Now you need to find which file is corrupting your PATH. The usual suspects, in order of likelihood:

~/.bashrc
~/.profile
~/.bash_profile
/etc/environment (system-wide, but rare)

If you can use grep for PATH assignments:

grep -n 'PATH=' ~/.bashrc ~/.profile ~/.bash_profile 2>/dev/null

Look for lines that don't include $PATH. A classic mistake is:

PATH=/opt/custom/bin

That wipes everything else. The correct pattern is:

export PATH="$PATH:/opt/custom/bin"

The $PATH preserves existing entries. If you find a bad line, comment it out with # at the start, then reload: source ~/.bashrc. Test with echo $PATH — you should see the standard directories plus your custom ones.

Another trigger I see a lot on Ubuntu 22.04: users append export PATH=~/bin after installing something with a script that assumes a fresh shell. That's fine in isolation, but if it runs in a non-interactive shell, it can override everything.

The 15-Minute Fix: Rebuild PATH from Scratch

If the above doesn't work, your PATH might be getting overwritten by something you can't easily spot — a startup script in /etc/profile.d/, a broken symlink, or a runaway alias. Time to get systematic.

First, check what PATH actually is right now:

echo $PATH

If it's empty or just one directory, then something in your login sequence is resetting it. Let's trace it. Start a fresh login shell and log output:

bash -lx 2>&1 | grep PATH

This shows every line that mentions PATH as your shell starts. You'll see each assignment in order. The last one to set PATH wins. That's your culprit.

Common hidden offenders:

/etc/profile.d/*.sh — some packages (like Java or Anaconda) add their own PATH lines. If one of them has a typo, it breaks everything.
~/.bash_login or ~/.profile — these run before .bashrc for login shells. If you have both, the later one might override.
A function or alias named export — yes, I've seen it. It shadows the builtin and does nothing.

Once you find the offending line, fix it or comment it out. Then test with a new terminal (don't just source — actually open a fresh one).

If you want to be extra safe, you can hardcode a fallback at the end of .bashrc:

if [ -z "$PATH" ]; then
  export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
fi

That's a safety net. If anything earlier in the chain wipes PATH, this restores a sane default. The reason this works is that -z "$PATH" checks for an empty string. If PATH is unset or empty, the conditional fires.

One more scenario: you're on a headless server and you lost SSH because your.bashrc exits on error. If you can't get a shell at all, use your provider's console (like AWS EC2 Instance Connect) or boot from a rescue image. Mount the disk and edit the file directly.

Prevention: Don't Let This Happen Again

Most of the time, this happens because someone wrote PATH=... without $PATH. Get into the habit of always using:

export PATH="$PATH:/new/dir"

And before you edit .bashrc, back it up: cp ~/.bashrc ~/.bashrc.bak. That 1-second habit saves you a 15-minute debugging session. Also, keep a copy of a known-good PATH in a comment at the top of your .bashrc so you never have to guess what the defaults are.

If you're on a distro that uses ~/.profile for login shells (like Debian-based), remember that .bashrc is only for interactive non-login shells. If you set PATH in .bashrc, it won't affect cron jobs or scripts. Put system-wide stuff in ~/.profile instead.

Bottom line: command not found is almost always a PATH problem. Fix the source, not the symptom. And never, ever run export PATH= in a script you don't fully understand.