Linux / Bash

Linux "Command Not Found" After Installing via apt

Getting "command not found" immediately after apt install reports success almost always means the installed binary isn't located in a directory your shell's PATH actually searches, or the package didn't actually complete installation the way the summary message suggested.

The Problem

You install a package expecting to immediately use its command-line tool:

sudo apt install some-tool
some-tool --version
bash: some-tool: command not found

apt reported the installation as successful, which makes the immediate "command not found" confusing.

Why It Happens

A handful of distinct situations produce this exact symptom, each with a different underlying cause:

  • The package installs its binary to a directory that isn't included in your shell's current PATH, which happens more often than expected with certain package types (Snap packages, some manually built tools, or packages targeting a non-standard install location)
  • Your current shell session's PATH was set before the installation and hasn't been refreshed — some package managers modify shell profile files, but those changes only take effect in new shell sessions, not the one you're currently using
  • The actual executable name doesn't match what you expect — a package name and its actual command-line binary name aren't always identical, and the true command name needs to be looked up rather than assumed
  • The installation genuinely failed partway through despite an apparent success message, particularly if there were warnings in the output that were easy to miss among a lot of other installation text

The Fix

First, confirm the package actually installed the files you expect, and find exactly where the binary landed:

dpkg -L some-tool | grep bin

This lists every file the package installed, filtered to show anything with "bin" in its path — typically revealing the exact location of the executable, which you can then compare against your current PATH.

Check your current PATH to see whether that directory is actually included:

echo $PATH

If the binary's directory isn't listed, add it either temporarily for the current session:

export PATH="$PATH:/path/to/binary/directory"

Or permanently, by adding the same export line to your shell's profile file (~/.bashrc, ~/.zshrc, or equivalent depending on your shell), then reloading it:

source ~/.bashrc

If you suspect a shell profile change was made by the installer but your current session simply hasn't picked it up yet, start a fresh shell session (open a new terminal, or explicitly re-source your profile) rather than assuming the installation itself is broken:

source ~/.bashrc
# or, more reliably, close and reopen your terminal entirely

If you're not sure of the actual command name, search for what the package actually provides rather than guessing based on the package name alone:

dpkg -L some-tool | grep -E '/(usr/)?bin/'

Some packages install a binary with a notably different name than the package itself — for example, a package named golang-go installs a command called go, not golang-go.

To rule out a genuinely incomplete installation, re-run the install command and carefully review the full output for any error or warning messages that might have scrolled past unnoticed the first time:

sudo apt install --reinstall some-tool

Still Not Working?

If the binary's location is confirmed to be in your PATH and the file genuinely exists, check whether it has execute permissions, since a file existing in a correct PATH directory without execute permission also produces a "command not found" error in some shells, rather than a more informative "permission denied":

ls -l $(dpkg -L some-tool | grep bin)

Look for the x permission bit — if it's missing, this points to a packaging issue rather than anything wrong with your own configuration, and reinstalling the package (or reporting the issue to the package maintainer, if it's a third-party repository) is the appropriate next step.

You might also like