A colleague runs `find /etc -name *.conf` from a working directory that happens to hold two files of its own, ntp.conf and rsyslog.conf. find prints 'paths must precede expression' and does nothing. What went wrong?
LPIC-1 Exam 101-500, objective 104. Devices, Linux filesystems, filesystem hierarchy standard medium
Machine-checked — no person has signed for it. This question was read against the source cited below by an automated pass, which found no contradiction. That is a weaker claim than it sounds: the same kind of process wrote the question, so it can confirm its own mistake.
Treat it as a good draft rather than as settled fact, and read the source below before you rely on it. It is not used in mock exams here — only questions a person has signed for are.
How these questions are written — where each question comes from, what the verification ledger records, and what happens when one is found wrong.
The options
Correct The shell expanded *.conf before find ran, so find received `-name ntp.conf rsyslog.conf` and read the second name as a second starting directory. Quoting the pattern stops the expansion.
Correct. Globbing happens in the shell, not in find. Once the expansion has produced two words, the first is taken as the argument to -name and the second looks like a path arriving after the expression has begun, which is the error reported.
Not correct -name cannot match a pattern containing a dot, so -path or -regex has to be used instead.
Wrong. A dot is an ordinary character in a shell pattern, which is what -name matches with. The one character -name genuinely cannot handle is a slash, because it tests the base name only.
Not correct find requires its tests in a fixed order, and -type f has to come before -name.
Wrong. Tests may be written in any order and are joined by an implicit AND. The complaint here is about a path appearing after the expression started, not about how the tests are arranged.
Not correct /etc holds no file matching *.conf, so find reports the unmatched pattern as an error.
Wrong. Matching nothing is not an error in find: it prints nothing and exits successfully. This failure happened before find had looked at /etc at all.
Why
The manual page for find says it in one line: enclose the pattern in quotes to protect it from expansion by the shell. `find /etc -name '*.conf'`, "*.conf" or \*.conf all pass the pattern through untouched. What makes the mistake so durable is that it usually looks like it works — with the shell's default settings a working directory containing no match passes *.conf through unchanged, and a directory containing exactly one match produces a command that runs perfectly while quietly searching for that single name. Only two or more matches produce the error, and only from the directory that has them.
Where this comes from
- Cited
- manual page find(1)
Practise this
Reading one question is not practice. The trainer will draw a short set from objective 104 and space the ones you get wrong.
More questions on this objective
- A new disk /dev/sdb has no partition table at all. Which command writes an empty GPT partition table onto it without dropping you into an interactive editor? machine-checked
- You need the partition /dev/sdc1 on a USB stick to carry a FAT32 filesystem so that Windows machines can read and write it. Which command creates it? machine-checked
- You have just run `mkswap /dev/sdb2`. Which command makes the kernel start using that swap area immediately, without a reboot? machine-checked
- Why is it dangerous to run e2fsck against an ext4 filesystem that is currently mounted read-write? machine-checked
- On an ext4 filesystem at /dev/sda1 you want an automatic check to be forced after every 30 mounts. Which command sets that? machine-checked
- `df -h /var` reports the filesystem 100% full, but `du -sh /var` accounts for only about half that space. Nothing is hidden under a mount point. What is the most likely explanation? machine-checked
All questions on Devices, Linux filesystems, filesystem hierarchy standard