How to Find Where a Command Lives on Linux (and What it Actually Does)

Every few weeks I find myself typing some command I have used for years, and I cannot remember where it lives on disk, what package it came from, or which man page I should actually read. This is the post I wish I had bookmarked. It is the one I am going to send to the next junior admin who asks me “where is grep, actually” and then watches me fumble for the right answer.

The commands below are the ones I use most often. I have organized them by the question they answer, not by alphabetical order, because the question is what I am usually trying to remember at 2 AM. Each one has a real example, the kind you can paste into a terminal and actually learn from.

The question I am always asking: where is the binary

The fastest way to find the path to a command is which, but which has a few well-known quirks. It searches the directories in your $PATH (an environment variable, basically a colon-separated list of folders, that tells the shell where to look for executable programs when you type a command name) and prints the first match it finds. It does not tell you about aliases (shortcuts you can define so that typing a short name runs a longer command) or shell functions. It does not always reflect what would actually run if you typed the command at a fresh prompt.

which python3
# /usr/bin/python3

type is the more honest answer. It tells you whether the name resolves to a binary, an alias, a shell function, or a built-in. This is the command I reach for when something is “weird” and I want to know what is actually running.

type ls
# ls is aliased to `ls --color=auto'
type cd
# cd is a shell builtin
type git
# git is /usr/bin/git

command -v is the POSIX-portable (POSIX is the family of standards that define how Unix-like systems behave, so “POSIX-portable” means the command works the same on Linux, macOS, BSD, and other Unix-like systems) version of the same idea. It is what you want to use in a shell script that needs to behave the same on macOS, Linux, and BSD.

command -v python3
# /usr/bin/python3

whereis is the older, broader tool. It searches a hard-coded list of standard directories for the binary, the source, and the man page. It is faster than which because it does not look at your $PATH, but it is also less accurate. I use it when I want a quick sanity check that a man page exists.

whereis grep
# grep: /usr/bin/grep /usr/share/man/man1/grep.1.gz

When I need to be more specific

which and type only find what is on your $PATH. Sometimes the binary you are looking for is in /usr/sbin, /usr/local/bin, or somewhere obscure that is not in the default $PATH. The fix is locate (if you have it installed and the database is fresh) or a direct find.

locate uses a database that is rebuilt periodically by a cron job, so it is fast but can be slightly out of date. Most distributions disable it by default, but it is a one-line install on every mainstream package manager.

sudo apt install mlocate   # Debian/Ubuntu
sudo dnf install mlocate   # Fedora
sudo updatedb              # build the database fresh
locate python3 | head

find is the slow, accurate, always-works fallback. The trick is to know where to start the search. Starting at / is reliable but slow. Starting at /usr or /opt is faster and catches most cases.

sudo find / -name "python3*" -type f 2>/dev/null

The 2>/dev/null (which redirects error messages, like “permission denied” on protected directories, into the void so you only see real results) is doing real work. Without it, you get a long list of “Permission denied” lines that obscure the actual hits. If you are root, you can drop it.

The package question: which package owns this file

This is the question that bites every junior admin at least once. You find a binary, you want to know what package it came from, and you do not know whether to install it, update it, or replace it with a newer version. The answer depends on the package manager.

On Debian and Ubuntu, dpkg -S searches the installed package database for the file. The output is the package name and the file path, which lets you reverse-lookup the owner.

dpkg -S /usr/bin/grep
# grep: /usr/bin/grep

On Fedora, RHEL, and CentOS, the equivalent is rpm -qf. The output format is similar: the package name and the version, separated by a tab.

rpm -qf /usr/bin/grep
# grep-3.11-9.fc41.x86_64

On Arch, the tool is pacman -Qo. Same idea, slightly different flag pattern.

pacman -Qo /usr/bin/grep
# /usr/bin/grep is owned by grep 3.11

If you want to know what files a package installed in the first place, the command is dpkg -L, rpm -ql, or pacman -Ql. This is the reverse direction: package to files, not files to package.

dpkg -L python3-minimal
rpm -ql python3
pacman -Ql python

The man page question: how do I read the right one

The man command opens the manual page for a given name. Most commands have a man page in section 1 (user commands). Some have man pages in multiple sections, and the same name can refer to different things in different sections. The classic example is printf. In section 1 it is the shell command. In section 3 it is the C library function. Same name, different documentation.

The fix is to specify the section explicitly.

man 1 printf
man 3 printf

man -k (or apropos) does a keyword search across the man page database. This is the right tool when you remember the concept but not the command name.

man -k "list files"
# ls (1)               - list directory contents
# dir (1)              - list directory contents
# vdir (1)             - list directory contents verbosely

If man -k returns nothing, the man page database is probably out of date. On Debian, the database is rebuilt by mandb, and you can run it manually. On Fedora, the equivalent is makewhatis or it is rebuilt automatically when you install the man-db package.

The “what does this command actually do” question

The man page is the canonical answer, but it is not always the easiest to read. The whatis command gives you the one-line description from the man page header. It is faster than opening the full man page when all you need is a reminder.

whatis grep
# grep (1)             - print lines that match patterns

For a slightly longer summary, info opens the GNU info manual for the command. Not every command has an info page, and the format is a little clunky, but it is the right tool when the man page is too brief.

info grep

If you want a practical example-based view, the --help flag is the unsung hero. Most GNU and BSD tools print a usage summary with the available options, and that summary is often enough to remind you of the right flag for a common task.

grep --help

Putting it together: my actual workflow

When I land on a new machine, the first thing I do is check what is installed. The commands I reach for, in order, are:

• which or type to find the path of a command I am about to run
• dpkg -S, rpm -qf, or pacman -Qo to find the package that owns a file
• man for the full documentation, or whatis for a one-line reminder
• --help for a quick list of flags

I do not reach for whereis often, because the $PATH is what determines what runs, and which/type is the more honest answer. I do not reach for locate or find unless the binary is not on my $PATH, which is a less common case than people think.

The pitfalls

The biggest pitfall is trusting which in a script. If the binary is in a non-standard location and the $PATH is set up correctly, which works. If the $PATH is not what you think it is, which will tell you about the wrong binary. The fix is command -v in scripts and type in interactive shells.

Another pitfall is assuming that the man page is the latest version. Most distributions backport (the process of taking a fix from a newer version of a package and applying it to an older version that the distribution still ships, so users get the fix without upgrading the whole package) new options into old tool versions, but the man page does not always get updated. If a flag is not behaving the way the man page says it should, check the tool’s --version and the upstream documentation.

A third pitfall is the locate database. The database is rebuilt on a schedule, not in real time. If you just installed a new package, the binary is on disk but locate will not see it for up to a day. Run sudo updatedb to rebuild the database manually.

Trade-offs

The tools above are old. They have been in Unix since the 1970s. The reason they have survived is that they do one thing and they do it well. The downside is that they are not consistent across distributions. The flag for “what package owns this file” is -S on Debian, -qf on Fedora, and -Qo on Arch. The flag for “what files does this package install” is -L on Debian, -ql on Fedora, and -Ql on Arch. The inconsistency is the cost of distribution-specific package managers, and there is no clean fix.

which and type are slightly redundant. type is strictly more powerful, but which is shorter to type and is the answer most people are looking for. I keep both in my muscle memory.

man pages are not beginner-friendly. The format is dense, the cross-references are hard to follow, and the convention of putting flags in brackets is not always explained. If you are learning a new tool, the right move is to read the man page, then read it again, then find a tutorial that uses the tool in a real workflow. The man page is the reference. The tutorial is the learning path.

What I would tell past me

If I could send a message back to the version of me that spent way too long typing find / -name "*python*" every time I could not remember where something was, I would say three things.

• type is the honest answer to “where is this command.” which is a shortcut, and the shortcut lies in corner cases. type is the command you want in scripts and on unfamiliar systems.
• The package-manager reverse-lookup is the command you will actually use most often. Knowing which package owns a file is the difference between fixing a system and breaking it. dpkg -S, rpm -qf, and pacman -Qo are worth committing to muscle memory.
• The man page is the last resort, not the first. Most commands have a --help flag that prints a useful summary. Most modern tools have a website with examples. Reach for man when you need the canonical reference, not when you need a quick reminder.

Bottom line

Finding a command on Linux is a solved problem. The tools are old, the flags are short, and the workflow is fast once you have practiced it. The commands I reach for most often are type (or which), the package-manager reverse-lookup for the distribution I am on, and man (or --help) when I need the documentation.

If you are learning Linux, the right move is to memorize type and the package-manager reverse-lookup for your distribution. The other tools are useful but secondary. The man page is the canonical reference, but it is not the first thing you should reach for when you are in a hurry.