Learn › Linux Foundations › Search
Final test: Chapter 15, Search. Twenty-five objectives on a real Debian 12 server: find from an absolute and a relative starting point, -name and -iname with quoted patterns, -type, -size, -mtime, -maxdepth, three -exec sweeps, locate, the staleness sequence rebuilt with updatedb, and find -print0 piped into xargs -0. Fifty minutes, graded from the commands you run and from the machine.
A service has left configuration files and logs in several directories. You need to find the right files, understand how current the results are, then make a small, verified change. This chapter teaches that investigation using the prepared ~/search tree.
You will use find to inspect directories now and locate to query an index built earlier. That difference matters when a missing search result could lead you to the wrong diagnosis.
This chapter covers the following topics:
What you already know: Chapter 2 listed the contents of one directory at a time with ls and named places with absolute and relative paths. This chapter searches a whole tree of directories at once, and asks the system questions ls cannot answer.
Objectives
After this chapter you can:
Use Start machine to open the real practice server. Read the explanation beside it, predict what the command will show, then inspect the actual terminal output. Guided exercise completion records practice, not independent mastery. The separate chapter assessment uses a fresh machine and its own checks.
Commands using ~/search work from any working directory. Alternatives beginning with search/ assume you are in /home/admin; use pwd to check and cd ~ to return there. A reconnect may open a new shell. The prompt's path is useful, but its colors and symbols can differ from the examples.
The listed output describes the prepared fixture. Directory order can vary. Compare the matching paths and what they mean, rather than expecting the same order on every run. Earlier changes in this session can also change later results.
Five questions before the material. A wrong answer costs nothing: the explanation states the fact and names the section that teaches it.
>>> find reads the directory entries it can access during this run and tests their names. It does not use the locate index. Permission errors or files changing during the walk can make the result incomplete, so read diagnostics too. Section 15.2 covers the walk.
>>> The shell expands a star into matching file names before the command runs. Quotes stop that, so find receives the star itself and applies it to every entry it meets. Section 15.3 covers it.
>>> locate searches a prepared database of paths. The index can omit configured locations, and results depend on access permissions. It is usually much faster than walking the same large tree again. Section 15.10 covers that tradeoff.
>>> A database is a picture of the disk at the moment it was built. Anything created since is missing from it, and the tool reports what the database holds without complaint. Section 15.11 covers it.
>>> Plain xargs splits input at unquoted whitespace and also interprets quotes and backslashes. The pipe itself only carries bytes; it does not split filenames. Section 15.12 pairs find -print0 with xargs -0 to preserve each complete path.
Every example in this chapter runs against one directory: ~/search. It holds configuration files, two small projects, media files, archived reports, an incoming directory and a scratch directory, arranged in the way a working server accumulates them.
Read ~/search/README.txt first. It describes the prepared tree, which you will inspect with the tools below. If you have already practiced here, your changes may still be present.
prompt: admin@server1:~$ answer: cat ~/search/README.txt ||| cat search/README.txt ||| cat /home/admin/search/README.txt output: search: the tree Chapter 15 searches ==================================== Everything in this directory exists to be found. It is a copy of the kind of tree a server accumulates: configuration files, two projects, media files, archived reports, an incoming directory and a scratch directory.
config/ four configuration files, one of them spelled in capitals projects/ alpha and beta, each with source, logs and a readme media/ two disk images, a spreadsheet whose name has a space in it, and a note archive/ reports from 2024 and 2025, untouched since they were written incoming/ what arrived most recently scratch/ three temporary files, safe to delete collected/ empty. Chapter 15 copies files into it.
Nothing here is needed by the server. Delete, copy and rename as the chapter asks: the machine is rebuilt from scratch on every launch. hint: Section 15.1. The reading tool from Chapter 5, then the path ~/search/README.txt.
Eight entries at the top level. Two of them matter before you start: scratch/ holds three temporary files that Section 15.9 deletes, and collected/ is empty until Section 15.9 fills it. Later you will also create incoming/recovered.txt and rebuild the locate index. Keep changes within the paths the lesson names.
find is the tool that walks a directory tree. You give it a starting point, which is the directory it begins in, and it reads that directory, then every directory inside it, and so on to the bottom. It prints the path of every entry it meets.
With nothing but a starting point, find prints everything. Start with the smallest directory in the tree, ~/search/config.
prompt: admin@server1:~$ answer: find ~/search/config ||| find search/config ||| find /home/admin/search/config output: /home/admin/search/config /home/admin/search/config/webhost.conf /home/admin/search/config/nginx.conf /home/admin/search/config/Backup.CONF /home/admin/search/config/hosts.allow hint: Section 15.2. The walking tool and one argument, the directory ~/search/config.
Five lines for four files. The first line is the starting point itself: find tests the directory you named as well as everything under it. Every path printed begins with the starting point exactly as you typed it, expanded from ~ to /home/admin by the shell.
The order is neither alphabetical nor the order the files were created. find prints entries in the order the directory itself stores them, and it does not sort. If you want a sorted list, Chapter 13 taught the tool that sorts.
A relative starting point depends on your working directory. Chapter 2 taught cd, which changes that directory. Check the real prompt path or run pwd; example prompts do not move your shell.
Change into the beta project, ~/search/projects/beta. Nothing is printed when it works.
prompt: admin@server1:~$ answer: cd ~/search/projects/beta ||| cd search/projects/beta ||| cd /home/admin/search/projects/beta output: hint: Section 2.6. The change-directory command from Chapter 2, then the path ~/search/projects/beta, which works from any directory.
cd normally prints nothing when it works. The path in your prompt should now end with ~/search/projects/beta; pwd confirms /home/admin/search/projects/beta. Relative paths start there. cd ~ takes you home again.
The starting point follows the same rules as any other path. Chapter 2 defined . as the directory you are standing in, so find . walks from where you are.
What changes is the output. find builds each result by joining the starting point to the rest of the path, so a relative starting point produces relative results.
The step before this one moved you into ~/search/projects/beta. Walk it from there, with the relative starting point rather than the full path.
prompt: admin@server1:~/search/projects/beta$ answer: find . ||| find ./ output: . ./src ./src/server.py ./ReadMe.md ./logs ./logs/build.log hint: Section 15.2. The walking tool and the single character Chapter 2 gave to the directory you are standing in, which the last step made ~/search/projects/beta.
Six entries. The first line is . itself; the other paths begin with ./, meaning they are relative to this working directory.
Look at the order: ./src is printed, then what is inside it, and only then ./ReadMe.md, which sits beside src at the top level. find goes all the way down one branch before returning for the next. That is why a result deep in the tree can appear before a file in the directory you started from.
Run cd ~ now, then pwd to confirm /home/admin. Do this before using the shorter search/... alternatives below. The ~/search/... versions remain valid from any directory.
A walk that prints everything is rarely what you want. Tests narrow it. A test is written after the starting point and asks one question about each entry find meets; only entries that answer yes are printed.
-name compares the name of the entry, which is the last part of the path, with the text you give it. The directories above it are not part of the comparison. Search ~/search for the file named webhost.conf.
prompt: admin@server1:~$ answer: find ~/search -name webhost.conf ||| find search -name webhost.conf ||| find /home/admin/search -name webhost.conf output: /home/admin/search/config/webhost.conf hint: Section 15.3. The walk over ~/search, then the test -name, then the name webhost.conf.
One line. find still walked the whole tree and tested every entry in it; the test threw away all but one. The path it prints is complete and absolute, because the starting point was absolute, so you can pass it straight to another command.
-name also accepts a pattern, which is a name with * standing for any run of characters. *.log means anything ending in .log.
The pattern has to reach find intact. Chapter 8 taught that the shell expands a star into matching file names before the command runs, so an unquoted pattern is replaced by whatever happens to be in the current directory. Quotes stop the shell from touching it. Single or double quotes both work. Search ~/search for every name ending in .log.
prompt: admin@server1:~$ answer: find ~/search -name '*.log' ||| find ~/search -name "*.log" ||| find search -name '*.log' output: /home/admin/search/projects/beta/logs/build.log /home/admin/search/projects/alpha/logs/build.log /home/admin/search/projects/alpha/logs/test.log hint: Section 15.3. The walk over ~/search, the test -name, then the pattern '*.log' in quotation marks so the shell hands it over untouched.
Three logs, in two different projects, found without knowing that either project existed. Two of them are called build.log; the full paths are what tells them apart.
The star matched build, test and everything before them in the name, but never a /. A pattern given to -name applies to the name alone, so no pattern written there can ever span two directories.
Linux treats README.txt, readme.md and ReadMe.md as three different names. A capital letter is as much a part of a name as any other character, and -name compares exactly.
This tree holds all three spellings on purpose. Ask ~/search for the lowercase one first.
prompt: admin@server1:~$ answer: find ~/search -name 'readme*' ||| find ~/search -name "readme*" ||| find search -name 'readme*' output: /home/admin/search/projects/alpha/readme.md hint: Section 15.4. The walk over ~/search with -name and the pattern 'readme*' in quotation marks, in small letters.
One hit, and two misses you cannot see. README.txt at the top of the tree and ReadMe.md in the beta project were both tested and both rejected, because their first letter is not r.
-iname is -name with capitalization ignored. The i stands for insensitive, meaning insensitive to case. Every other rule is the same: it compares the last part of the path, patterns work, and quoting is still required. Ask ~/search again.
prompt: admin@server1:~$ answer: find ~/search -iname 'readme*' ||| find ~/search -iname "readme*" ||| find search -iname 'readme*' output: /home/admin/search/README.txt /home/admin/search/projects/beta/ReadMe.md /home/admin/search/projects/alpha/readme.md hint: Section 15.4. The same line as Exercise 15-7 with -iname in place of -name.
Three hits from the same pattern. The pattern itself may be typed in any capitalization, because it is the comparison that ignores case, not the text.
-iname is the test for a name whose capitalization you are not sure of, and -name is the test for one you are.
A directory tree holds different kinds of thing. -type tests which kind an entry is, using one letter:
d a directoryf a regular file, meaning ordinary content on the diskl a symbolic link, the shortcut Chapter 6 taughtA walk with -type d prints the shape of the tree and nothing else. Print the shape of ~/search.
prompt: admin@server1:~$ answer: find ~/search -type d ||| find search -type d ||| find /home/admin/search -type d output: /home/admin/search /home/admin/search/collected /home/admin/search/scratch /home/admin/search/incoming /home/admin/search/config /home/admin/search/media /home/admin/search/projects /home/admin/search/projects/beta /home/admin/search/projects/beta/src /home/admin/search/projects/beta/logs /home/admin/search/projects/alpha /home/admin/search/projects/alpha/conf /home/admin/search/projects/alpha/src /home/admin/search/projects/alpha/logs /home/admin/search/archive /home/admin/search/archive/2025 /home/admin/search/archive/2024 hint: Section 15.5. The walk over ~/search, then -type d, the letter that means directory.
Seventeen directories, including the starting point. There are seven immediate subdirectories of ~/search. Alpha contains conf, src and logs; beta contains src and logs. This command shows directories without listing their regular files.
-type f is the other side of the same test. It is worth typing even when a directory holds only files, because it states what you meant, and later sections pair it with tests that would otherwise match directories too. List the files of ~/search/media.
prompt: admin@server1:~$ answer: find ~/search/media -type f ||| find search/media -type f ||| find /home/admin/search/media -type f output: /home/admin/search/media/snapshot-2026-01.img /home/admin/search/media/disk-image.img /home/admin/search/media/notes.txt /home/admin/search/media/camera export.csv hint: Section 15.5. The walk over ~/search/media, then -type f, the letter that means an ordinary file.
Four files, and the directory itself is not among them. Look at the last line: camera export.csv has a space inside its name. find prints it as one path on one line, which is correct, and Section 15.12 shows what happens when another command has to read that line.
-size tests how big an entry is. The number is followed by a letter for the unit:
c bytesk units of 1024 bytes, also called kibibytes (KiB)M units of 1024 KiB, also called mebibytes (MiB)G units of 1024 MiB, also called gibibytes (GiB)A number written with no letter after it does not mean bytes. It counts blocks of 512 bytes, which is rarely what anyone intends, so write the letter every time.
find first rounds the file size up to a whole unit. It then compares that count: + means greater than, - means less than, and no sign means equal. +1M matches sizes greater than 1 MiB (1,048,576 bytes). The next examples show why 1M without a sign has a different meaning.
prompt: admin@server1:~$ answer: find ~/search -size +1M ||| find search -size +1M ||| find /home/admin/search -size +1M output: /home/admin/search/media/disk-image.img hint: Section 15.6. The walk over ~/search, then -size +1M: a plus for larger than, the number one, the letter for megabytes.
One file in the whole tree: disk-image.img, which holds 2048 kilobytes. This is the question to ask when a disk is filling up, because it names what is big rather than what is there.
The other image is 700 KiB, below the 1 MiB threshold. Its rounded MiB count is 1, which is not greater than 1. It therefore does not match +1M.
The same test with a smaller unit finds more. The media directory ~/search/media holds two disk images, one of 2048 kilob
Practice Chapter 15. Search: find, locate and updatedb in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.