Concepts·LPIC-1

Finding your way on an unfamiliar machine

Before any objective, there is the skill of working out what a machine will actually do. This guide covers the three things that decide it: whether a command is a builtin or a program, where the shell looks and in what order, and how to find documentation from the command line - including the manual sections that explain why man passwd and man 5 passwd are different pages.

Start Here Guide 3 of 33 Beginner

OSUbuntu 26.04 LTS
Kernel7.0.0-30-generic
systemd259
TimeAbout 15 min

One Debian-family host. Everything here is read-only and behaves the same on either family.
Server Name	IP Address	OS	Roles	CPU	RAM	HDD
LPIC1-A01	192.168.0.76	Ubuntu 26.04 LTS	Debian-family host - dpkg and apt, which objective 102.4 names	2 Core	4 GB	50 GB

This guide includes

Use this before any objective. This matters because which and the shell can disagree - a command is not always a program, and the answer depends on which of them you asked.

finding that a command is not always a program, with type -a
seeing where which disagrees with the shell
reading $PATH as a list, in the order that decides the winner
finding a manual page you did not know existed, in another section

Before you start

what-lpic-1-asks

A command is not always a program
type -a shows every candidate, in the order the shell considers them.
bash Example session
```
$type -a echo; echo "---"; type -a lsecho is a shell builtinecho is /usr/bin/echoecho is /bin/echo---ls is /usr/bin/lsls is /bin/ls$type -a cd; echo "--- cd MUST be a builtin: a child process could not change your directory"cd is a shell builtin--- cd MUST be a builtin: a child process could not change your directory
```
Note
echo exists three times and the builtin wins. That matters because the builtin and /usr/bin/echo do not support the same flags - echo -e behaves differently between them and between shells. Scripts that need predictable behaviour use printf, which is why every serious script you read does.

cd MUST be a builtin, and the reason is worth understanding. A program runs in a child process; changing directory in a child cannot affect the parent. If cd were a program it would change its own directory and exit, leaving you exactly where you were. The same argument explains export, ulimit and umask.

Two paths for the same binary is a compatibility artefact. /bin is a symlink to /usr/bin on both these distributions - the "usr merge" - so /bin/echo and /usr/bin/echo are one file reached two ways.

type is a builtin itself, which is why it knows about functions, aliases and builtins that an external program could never see.

Expected resultecho is a shell builtin AND /usr/bin/echo AND /bin/echo; ls is only a program; cd is only a builtin.

Success conditionYou can tell what will actually run before you run it.
Where `which` disagrees with the shell
Two tools that look interchangeable and are not.
bash Example session
```
$which echo; command -v echo; echo "--- which finds the binary, command -v finds what will actually run"echo: shell built-in commandecho--- which finds the binary, command -v finds what will actually run
```
Note
They are answering different questions. command -v is a POSIX shell builtin that reports what THIS shell will run, including builtins, functions and aliases. which is an external program - it cannot see your shell's state at all, and different distributions ship different implementations of it with different output.

Which is why scripts should use command -v. It is always present, it is POSIX, and its exit status is the reliable test for "does this command exist". which is not installed by default everywhere - a script depending on it can fail on a minimal container for a reason that takes a while to find.

The exam asks this directly, and the wrong answer sounds perfectly reasonable. Remember the distinction as: which finds a FILE, command -v finds what will actually RUN.

type is the interactive tool of choice, because type -a shows you every candidate rather than just the winner - which is how you diagnose a command that is not the one you meant.

Expected resultwhich reports echo: shell built-in command; command -v reports echo.

Success conditionYou know which tool to trust in a script.
Where the shell looks, and in what order
$PATH is a list, and the order is the whole story.
bash Example session
```
$echo $PATH | tr ':' '\n'/usr/local/sbin/usr/local/bin/usr/sbin/usr/bin/sbin/bin/usr/games/usr/local/games/snap/bin$echo $PATH | tr ':' '\n' | head -1; echo "--- the FIRST match wins, which is how a local bin shadows a system one"/usr/local/sbin--- the FIRST match wins, which is how a local bin shadows a system one
```
Note
The first match wins, and nothing tells you a second one existed. /usr/local/bin sits ahead of /usr/bin on purpose: it is where locally installed software goes, and it is meant to shadow the packaged version. That is a feature when you intended it and a mystery when you did not.

Which is why type -a is the diagnostic. A command behaving like an older version usually means a second copy earlier in $PATH.

sudo uses a DIFFERENT path. secure_path in /etc/sudoers replaces your $PATH entirely for the sudo'd command, which is why sudo mycommand can report "command not found" for something you can run perfectly well yourself. This is examined, and it is a genuine daily annoyance.

A trailing or empty element means the current directory, and that is a real security problem: a file named ls in a directory you cd into would run instead of the real one. . does not appear in either of these machines' paths, and should not appear in yours.

Expected resultNine directories, /usr/local/sbin first and /snap/bin last.

Success conditionYou can explain why a command ran the version you did not expect.
Reading a manual page you did not know existed
The same word can be several different pages.
bash Example session
```
$man -f passwd 2>/dev/null | head -4; echo "--- the same word in several manual sections"passwd (1)           - change user passwordpasswd (1ssl)        - OpenSSL application commandspasswd (5)           - the password file--- the same word in several manual sections$apropos -s 1 'list directory' 2>/dev/null | head -3; echo "--- search by description when you do not know the name"dir (1)              - List directory contents. Ignore files and directories ...gnudir (1)           - list directory contentsgnuls (1)            - list directory contents--- search by description when you do not know the name$man 5 passwd | head -6; echo "--- section 5 is the FILE, section 1 is the command"PASSWD(5)                File Formats and Configuration               PASSWD(5) NAME       passwd - the password file DESCRIPTION--- section 5 is the FILE, section 1 is the command
```
Note
The number in brackets is the manual SECTION, and it changes the answer. Section 1 is user commands, 5 is file formats, 8 is administration. man passwd gives you the command; man 5 passwd gives you the format of /etc/passwd. A question about the fields in that file is answered by section 5, and a candidate who does not know sections exist will read the wrong page and conclude the manual is unhelpful.

man -f is whatis; man -k is apropos. The first matches the NAME exactly and tells you which sections exist. The second searches descriptions, which is what you want when you know what you need but not what it is called - the search here found dir from the phrase "list directory".

If apropos reports nothing at all, the index is missing rather than the pages. sudo mandb rebuilds it. On a minimal install the manual pages themselves may be stripped out entirely, which is worth knowing before you rely on them in a container.

man 7 is the section people forget - conventions and overviews. man 7 hier explains the whole filesystem hierarchy, which is examined in Topic 104 and is sitting on every machine you will ever be asked about.

Expected resultpasswd (1) the command, passwd (5) the file, and passwd (1ssl) from OpenSSL - then a description search, then section 5 itself.

Success conditionYou can find documentation on a machine with no browser.

Troubleshooting

which names a binary but the shell runs something else.

Why: which is an external program that searches PATH only. It cannot see shell builtins, functions or aliases, and the shell prefers all three.

Fix:Use type -a <name>, which lists every candidate in the order the shell considers them - echo is a builtin AND /usr/bin/echo AND /bin/echo on this machine.
A command is installed and still reports command not found.

Why: Its directory is not in PATH for this shell - commonly /usr/sbin for a non-root user, or a directory added only by a login profile.

Fix:echo $PATH and compare with the file's location from command -v in a root shell. Order matters: the nine directories here are searched left to right, /usr/local/sbin first.
man <name> shows the wrong page, or one you did not expect.

Why: The same name exists in several sections - passwd(1) is the command, passwd(5) is the file format, and passwd(1ssl) comes from OpenSSL.

Fix:man -f <name> or whatis <name> lists every section. Ask for one directly with man 5 passwd, and search all of them with man -k <keyword>.

Official sources

← All LPIC-1 guides

Finding your way on an unfamiliar machine

This guide includes

Before you start

A command is not always a program

Where `which` disagrees with the shell

Where the shell looks, and in what order

Reading a manual page you did not know existed

Troubleshooting

Official sources