Part 5

Search, select and transform without opening every file

Searching is where the terminal stops feeling like a faster file manager and starts feeling like a way to reason about a project. The important skill is not a clever query; it is reducing a broad question until the answer is small enough to trust.

Search is a question you ask the project

In a graphical file manager you often navigate first and decide what matters after opening folders. A search command reverses that order: describe the property you care about — a name, a text fragment, a type or a starting path — and let the tree answer.

This is especially powerful in unfamiliar projects. You do not need to know where every configuration file lives before you begin; you can ask progressively narrower questions and build a map from evidence.

Prepare a tiny search space you can safely change

Create one text file in project/search, paste the starter block below, then copy it. The second copy is deliberately changed from alpha to beta, so the directory contains both shared text and one useful difference.

A controlled fixture matters because search and replacement are easiest to learn when you already know the correct answer. First learn what the commands should find; only then point them at a real codebase.

Start the file with this

project=alpha
status=draft
owner=Max
note=rename images before release

install md code copy find replace stat attr

cd lil-playground

md project/search

code project/search/notes.txt -n

copy project/search/notes.txt project/search/notes-2.txt

replace alpha beta project/search/notes-2.txt -w

A filename and the text inside it are different dimensions

find notes -f searches names. find draft -t searches text content. The two modes answer different questions, and combining -t, -e and -p lets you state both the content and the boundaries of the search.

When a query returns too much, do not immediately add complexity. First ask which dimension is wrong: starting path, file type, extension, case or whether you meant names rather than contents.

find notes -f -p project/search

find draft -t -p project/search

find owner -t -e txt -p project/search

Narrow first; recurse broadly only when the question requires it

A broad recursive search over a large project can be useful, but it is rarely the best first move. Start in the smallest directory that can contain the answer, decide whether you want files or directories, and make case sensitivity explicit when it matters.

This habit scales beyond find. Most safe terminal work is the same operation: constrain the input until the resulting set is understandable, then act on that set.

find project -F -p .

find status -t -h -p project/search

find Max -t -c -p project/search

Mass replacement should begin as a report

replace previews by default. That is a deliberate safety model: you can see which files and occurrences would change before any file is written. Only after the preview matches your intention do you add -w; -b can also create backups.

The sequence preview → inspect → write → search again is far stronger than “run replacement and hope”. It turns a potentially destructive bulk edit into an observable procedure.

replace draft reviewed project/search -r -e txt

replace draft reviewed project/search -r -e txt -w -b

find reviewed -t -p project/search

Content is not the only evidence a file gives you

stat and attr answer questions that text search cannot: size, MIME type, dimensions, timestamps, permissions and other metadata. Sometimes the fastest way to identify the right file is not what it contains but what kind of object it is.

Treat metadata as another filter in your mental model. Search finds candidates; metadata helps you confirm that the candidate is the object you intended to touch.

stat project/search/notes.txt

attr project/search/notes.txt size

attr project/search/notes.txt mime

A verified transformation is a small technology

Once you have a safe sequence — locate draft values, preview a replacement, write with backups, verify the new text — save it as a .lil file. The script is no longer a random collection of commands; it records a repeatable method.

This is how an archive of personal scripts becomes valuable. The useful unit is not “a command I remember”, but “a procedure whose assumptions and checks I already understand”.

Keep this as a script

Save this as review-status.lil after you have verified the preview on your own fixture. It searches for the old value, previews the change, writes with backups, confirms the new value and inspects one representative file.

#lil
@install find replace stat attr
cd lil-playground
find draft -t -p project/search
replace draft reviewed project/search -r -e txt
replace draft reviewed project/search -r -e txt -w -b
find reviewed -t -p project/search
stat project/search/notes.txt