DEV Community

Cover image for How to Fix 'command not found' (Without Reinstalling Everything)
SystemCraftDev
SystemCraftDev

Posted on Originally published at systemcraftpress.com

How to Fix 'command not found' (Without Reinstalling Everything)

#bash #cli #beginners #tutorial

Adapted from the Command Line Essentials Companion Guide.

You install something, open a fresh terminal, type the command, and get bash: python3: command not found — or on Windows, 'python3' is not recognized as an internal or external command. The installer said it finished successfully. You can probably even find the program in your applications folder. And yet the terminal insists it doesn't exist.

The instinct at this point is usually to reinstall, or install a second copy from somewhere else, hoping one of them "takes." That almost never fixes it, because reinstalling doesn't address what's actually wrong.

What the error is actually telling you

When you type a command, the shell doesn't scan your whole computer looking for it. It checks a specific, ordered list of directories — stored in an environment variable called PATH — and stops at the first match it finds. command not found doesn't mean the program doesn't exist anywhere on your machine. It means none of the directories in that list happen to contain it.

That distinction matters, because it splits into three genuinely different problems:

  1. A typo. gerp isn't a command; grep is. This is the most common cause by a wide margin, and the easiest to rule out first.
  2. It isn't installed at all. The program genuinely doesn't exist on this machine yet.
  3. It's installed, but not somewhere the shell is looking. This is the one that catches people off guard — the software is sitting on disk, correctly installed, just outside every directory PATH currently checks.

Reinstalling only ever fixes cause 2. If your actual problem is 1 or 3, a second install just gives you a second copy of a program that was never the issue.

The fix, step by step

  1. Check for a typo first. Read the command back character by character. It sounds too simple to be worth a step, but it resolves this error more often than everything else combined.
  2. Confirm whether it's installed at all, independent of whether the shell can currently find it: 
   which python3
Enter fullscreen mode Exit fullscreen mode

If which prints a path, it's installed and the shell can find it — so the error was probably a typo or a stale terminal (see below). If which prints nothing, move to step 3.

  1. Check what the shell is actually searching: 
   echo $PATH
Enter fullscreen mode Exit fullscreen mode

This prints the exact list of directories, in the exact order they're checked. If the folder containing your program isn't in that list, you've found the real cause — not a broken install, just an incomplete search path.

  1. If it needs to be added, add it — and make the change permanent by putting it in your shell's startup file (~/.bashrc, ~/.zshrc, or equivalent), not just typing it into the current session, or it'll be gone the next time you open a terminal.

Two mistakes worth knowing about ahead of time

Editing your startup file and expecting it to take effect immediately. A change to ~/.bashrc only applies to new terminal sessions. The terminal you already have open won't see it until you either close and reopen it, or explicitly reload the file:

source ~/.bashrc
Enter fullscreen mode Exit fullscreen mode

This is one of the most common "I fixed it and it's still broken" moments in terminal use — the fix worked, the current session just hasn't picked it up yet.

Assuming "not found" and "not installed" are the same thing. They frequently aren't. Running which <command> before doing anything else tells you immediately which situation you're actually in, so you're not troubleshooting a PATH problem as if it were a missing install, or reinstalling software that was never the problem.

A debugging habit that works

Before changing anything, ask which of the three causes you're actually looking at: typo, not installed, or not on PATH. which <command> answers that in one line — present it's a PATH problem, absent it's genuinely missing (or the name really is wrong). Fixing the right one of those three takes seconds. Guessing between them, and reinstalling on a hunch, is how a two-minute problem turns into a twenty-minute one.

If you'd like more posts like this sent straight to your inbox, subscribe to the newsletter.

Prefer to dig in yourself? The Command Line Essentials repo on GitHub has more free examples and exercises.

Top comments (0)