Linux / Bash

How to Fix "bash: command not found" After Updating PATH Variable

4 min read by DebuggedIt

Quick answer

You add a new directory to your PATH, expecting a command to work afterward, but the shell still can't find it. This almost always means the change either...

You add a new directory to your PATH, expecting a command to work afterward, but the shell still can't find it. This almost always means the change either didn't actually take effect in your current shell, got overwritten later in your config, or points at a directory that doesn't contain what you think it does.

The Problem

You edit your shell config, open a new terminal, and the command still fails:

$ mytool --version
bash: mytool: command not found

Checking PATH shows your new directory isn't actually there, even though you're sure you added it:

$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Or the directory is present, but the binary still isn't found:

$ echo $PATH
/home/user/tools/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin
$ which mytool
$ echo $?
1
How bash resolves a command mytool search each dir in $PATH, in order first executable match wins, others ignored Not in the list, not executable, or shell never reloaded PATH -> bash: command not found

Why It Happens

Bash searches every directory listed in PATH, in order, for an executable matching the command name, and it caches the results of that search per session using a hash table. This error after a PATH edit usually comes from one of these:

  • You edited the wrong config file for your shell or your terminal setup β€” ~/.bashrc vs ~/.bash_profile vs ~/.profile get sourced in different situations (interactive shell, login shell, non-interactive shell), and editing the wrong one means the change never loads.
  • You edited the file correctly but didn't reload it, or opened a new terminal tab that inherited the old PATH from before the edit if it was already running.
  • A later line in your config file overwrites PATH entirely instead of appending to it, silently discarding your addition.
  • The binary genuinely isn't in the directory you added, or it's not marked executable.
  • Bash's command hash table has a stale cached location for the command name from before you made the change.

The Fix

First, confirm which config file your shell actually loads. For an interactive non-login shell (most terminal emulators), that's ~/.bashrc:

echo 'export PATH="$HOME/tools/bin:$PATH"' >> ~/.bashrc

Reload it in your current session instead of opening a new terminal:

source ~/.bashrc

Verify the directory is actually in PATH now:

echo $PATH | tr ':' '\n' | grep tools

Check that the binary actually exists and is executable inside that directory:

ls -la ~/tools/bin/mytool
-rw-r--r-- 1 user user 8420 Aug  7 10:02 mytool

If the permissions show no x, make it executable:

chmod +x ~/tools/bin/mytool

Make sure you're appending, not overwriting β€” export PATH="/new/dir" replaces the whole variable, wiping out /usr/bin, /bin, and everything else, which breaks far more than just your new command:

# Wrong β€” destroys the rest of PATH
export PATH="/home/user/tools/bin"

# Correct β€” prepends while keeping everything else
export PATH="/home/user/tools/bin:$PATH"

If you suspect a stale hash entry, clear it explicitly:

hash -r

Still Not Working?

If the command works when you type the full path but not by name alone, and everything above checks out, look for a later line in your config that resets PATH after your addition β€” config files are read top to bottom, and a later unconditional export PATH=... silently overrides an earlier one:

grep -n 'PATH' ~/.bashrc

This lists every line touching PATH with line numbers, so you can confirm your addition is the last one to run, or move it to the bottom of the file if something else is overwriting it afterward.

It's also worth understanding the difference between login and non-login shells, since this trips people up constantly when the config edit "should have worked." A login shell (what you get connecting via SSH, or opening a fresh terminal on some Linux distributions and window managers) reads ~/.profile or ~/.bash_profile, while an interactive non-login shell (a new tab in most desktop terminal emulators) reads ~/.bashrc instead β€” and by default, ~/.bash_profile doesn't automatically source ~/.bashrc unless you've explicitly added a line to do so. If you're editing one file but your terminal is actually reading the other, your changes will never take effect no matter how many times you reload or restart the terminal:

cat ~/.bash_profile
if [ -f ~/.bashrc ]; then
    . ~/.bashrc
fi

If that block is missing from ~/.bash_profile, add it so both files stay in sync regardless of which type of shell session you open, and your PATH additions apply consistently everywhere.