Learn › Linux Foundations › Bash Shell Environment
whereis - a hands-on Linux lab on a real virtual machine.
Find the full address of a command with whereis. Read the one-line answer (binary, manual page, and source or config), narrow it with -b, -m, and -s, and understand why whereis differs from which: whereis sweeps a fixed set of standard system directories and finds the man page and source, while which walks your PATH and returns only the executable. Paths vary by machine, so the drills teach the shape and the moves.
You just learned to ask the shell where a program lives. which handed you one answer: the single path the shell would run. That is often all you want. But a command is more than its program file. It usually ships with a manual page, the built-in help you read with man, and sometimes a config file too. Those live in different folders, and which never mentions them.
So here is the gap this lesson closes. When you want the WHOLE address of a command, not just its program but its manual and its source and its config, in one line, you reach for a different tool. It is called whereis, and it goes looking in every place a command's pieces are known to hide.
The black boxes in this lesson are a practice terminal: a safe sandbox that only checks the one command each step teaches, so you cannot break anything. Where an output shows a full path like /usr/bin/ls, that path is this machine's; on yours it may sit elsewhere. The BEHAVIOUR and the SHAPE of the answer, not the exact folder, are the lesson, and those are the same everywhere.
whereis locates the pieces of a command in one shot: its binary (the program file the shell runs), its manual page (the help text man shows), and its source or config, if any exist. It prints them all on a single line, starting with the name you asked about.
Think of it like looking someone up and getting their home address, their work address, and their mailbox all at once, instead of just one of the three. which gives you the one address the shell uses. whereis gives you the whole file on where that command lives.
One thing to know up front. whereis does not search your PATH, the list of folders which walks. It searches its own fixed set of standard system directories, the usual places binaries, manuals, and sources are kept. That difference is why the two commands can disagree, and you will see it clearly by the end.
Start with a command you know cold: ls. Ask whereis where all of its pieces live. You hand it the bare name, nothing else:
whereis ls
prompt: student@linuxcamp:~$ answer: whereis ls output: ls: /usr/bin/ls /usr/share/man/man1/ls.1.gz hint: Type the word whereis, a space, then ls: whereis ls
One line, and it packs two answers. First comes the name you asked about, ls:, with a colon. Then the pieces, left to right. /usr/bin/ls is the binary, the actual program the shell runs when you type ls, the same path which ls would have given you. After it, /usr/share/man/man1/ls.1.gz is the manual page, the compressed help file that man ls opens for you. So in one line whereis told you both where the program lives and where its documentation lives. which would have shown you only the first.
Those two paths, /usr/bin/ls and /usr/share/man/man1/ls.1.gz, belong to the machine this was captured on. On YOURS the folders may differ, and the man-page filename can carry a different version. What stays the same everywhere is the SHAPE: the name and a colon, then the binary path, then the man-page path. Read the shape, not the exact folders.
Not every command stops at two pieces. Some ship a config file as well, and whereis will list that too. Look up bash itself, the shell you are typing into, and watch a third piece appear:
whereis bash
prompt: student@linuxcamp:~$ answer: whereis bash output: bash: /usr/bin/bash /usr/share/man/man1/bash.1.gz /etc/bash.bashrc hint: Same whereis as before, then the name bash: whereis bash
Three pieces this time, same left-to-right order. /usr/bin/bash is the binary, the shell program. /usr/share/man/man1/bash.1.gz is its manual page. And the new one, /etc/bash.bashrc, is a config file, a system-wide settings file bash reads when it starts. whereis swept its standard directories, found all three, and laid them out on one line. That is the strength of the tool. Whatever pieces of a command exist, it gathers them so you do not hunt each folder yourself.
Again the exact paths are this machine's and yours may differ. The lesson is the pattern: whereis prints as many pieces as it finds, binary first, then manual, then any source or config, all on the one line after the name. A command with more pieces simply prints a longer line.
Sometimes the full line is more than you want. You care about ONE thing: just the program, or just the manual. whereis has flags that narrow the answer. -b stands for binary, and prints only the program path. -m stands for manual, and prints only the man-page path. (There is also -s for source, the same idea for source code.)
Ask for ls again, but this time only its binary:
whereis -b ls
prompt: student@linuxcamp:~$ answer: whereis -b ls output: ls: /usr/bin/ls hint: Add the -b flag between whereis and ls: whereis -b ls
The man page dropped away. -b told whereis to report the binary and nothing else, so you got the name, a colon, and the single program path. Swap the flag for -m and you flip to the other half: whereis -m ls prints ls: /usr/share/man/man1/ls.1.gz, only the manual page, no binary. These flags are how you pull one piece out of the full line when the rest is noise. Your own paths will differ from this machine's, but the SHAPE, name then one narrowed piece, holds everywhere.
What happens when you ask about a name that does not exist anywhere it looks? Not an error, and not a crash. whereis prints the name, a colon, and then nothing after it, because it searched its standard folders and turned up no binary, no manual, no source. An empty answer IS the answer. Try it with a made-up name:
whereis notacommandxyz
prompt: student@linuxcamp:~$ answer: whereis notacommandxyz output: notacommandxyz: hint: Type whereis, a space, then the made-up name notacommandxyz: whereis notacommandxyz
Read that output carefully: notacommandxyz: with nothing after the colon. That is whereis telling you it found no pieces at all in the directories it searches. It is NOT an error message, so there is no red text and no failure to react to. When you see a name and a bare colon, the takeaway is simple: nothing about that command lives in the standard system locations. Check the spelling first, then whether the tool is even installed.
You now know two commands that find where things live, and it matters that you know when each lies to the other. which walks your PATH, the exact list of folders your shell searches, and prints only the one executable it would run. whereis ignores your PATH entirely and sweeps its own fixed set of standard system directories, gathering the binary, the manual, and the source.
That is why their answers can differ. A tool in an unusual folder on your PATH shows up in which but may be missed by whereis. And whereis shows you the man page and config, which which never mentions. Neither is wrong; they answer different questions.
A quick way to remember it: which answers "what will run," and whereis answers "where is it all." When you are debugging which version of a tool actually executes, reach for which. When you want the full address, program plus manual plus config, reach for whereis.
Scaffolding off. No command is printed this time. You have every piece you need.
You are writing up notes on the ls command and you want to open its manual page in an editor, so you need the exact path to that man-page file, and nothing else. Not the binary, not a config, just the manual. Ask whereis for ls, but narrow the answer to only its manual page.
prompt: student@linuxcamp:~$ answer: whereis -m ls output: ls: /usr/share/man/man1/ls.1.gz hint: You want only the manual page. Think whereis, then the manual-only flag -m, then ls.
That is the narrowing move. -m told whereis to report the manual and nothing else, so you got the name and the single man-page path, no binary in sight. Your own path and version may read differently from this machine's, but the shape, name then one man-page path, is what you will see anywhere. You recalled the flag from memory rather than copying it, which is the same recall the real machine will ask of you.
You earned this cheat sheet. Every row is a form of whereis you just ran:
The one idea to carry with you: whereis gives you the FULL address of a command, program plus manual plus source, from a fixed set of standard directories, where which gives you only the one executable your PATH would run.
whereis reads the line left to right in a fixed order: binary first, then the manual page, then any source or config. So even on a long line you can tell the pieces apart by position, the first path is always the program the shell runs.
The practice terminal has shown you what whereis does. You read the two-part line for ls and watched a third config piece appear for bash. You narrowed the answer with -b and -m, saw the bare-colon result when nothing is found, and lined whereis up against which so you know which to reach for. Every one of those you typed yourself.
The Bash Environment module ends with one real Linux machine, the Bash Environment capstone mission, and that is where you run whereis for real. A VM boots just for you, with its own binaries, its own manual pages, and its own PATH. It hands you objectives that use exactly what you practiced across this module: aliases, variables, PATH, and the tools that locate what those settings point at, whereis among them. One difference from here: the mission shows no commands. You read the objective, you recall the command, you type it. That recall is what makes it stick.
Finish the other Bash Environment lessons, then go find the full address of a real command for yourself.
Practice whereis in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.