Module 2: Working with Files and Text

1. Introduction: creating, finding, and reading without opening an editor

Description

By the end of this lesson you will be able to tell apart when a question about your own filesystem gets solved by searching by name, type, size, or date — finding where a file lives — and when it gets solved by searching inside its content — finding what it says — and you will be able to explain with a concrete example why the graphical file explorer, the one you use daily with clicks, stops being enough the moment a project grows past a folder with a dozen files.

That distinction is not a technicality of this module: it is one you are going to use every day once you work on real projects. You SSH into a production server to look into an incident and there is no Finder or Windows Explorer there — just a terminal. You inherit a two-hundred-file repository written by someone who no longer works at the company and need to know, before pushing it to a public repository, whether someone left a hand-written password in the code. In both cases, knowing how to point with the mouse no longer helps you. Knowing how to ask the filesystem, it does.

Connection to the module: module 1 taught you to move around the directory tree and look at what is in each spot — cd, ls, pwd. This module teaches you to act on that tree: you are going to create structure, copy and move and delete with judgment, read files of any size, locate any file on your machine, and find any line of text within an entire project. This lesson is the full map of that journey, and a warning worth reading before typing the first command: starting in lesson 3, this module hands you the power to delete things forever.

The magnifying glass that stops being enough

Think about how you search for something on your own desktop, with a dozen loose files: you look at the names, recognize the one you were after, done. That method works because your eye can scan twelve names in half a second and your memory already roughly knows what to expect from each one.

Now imagine you inherit a project from someone else: a repository with thousands of files, dependency folders with hundreds of subfolders you never wrote, names that mean nothing to you yet. The same method — look at names and recognize — stops working, not because you are less capable, but because the problem changed scale. And if that project also lives on a server you connect to over SSH, you do not even have the option of opening a window with icons: there is no window. There is a terminal, a list of commands, and nothing else.

That is the real limit of the graphical file explorer, and it has three distinct faces:

Existence. The graphical explorer needs, first of all, a graphical interface. A production server, a freshly spun-up container, a virtual machine you enter over SSH: none of those environments ship one. If your only search tool depends on clicks, in those places you have no search tool at all.
Combined precision. Questions like "the configuration files modified in the last 24 hours that also weigh less than 1 kilobyte" are natural to say in a sentence, but building that exact combination of criteria click by click — opening a filter panel, choosing type, choosing date, choosing size, confirming — is slow and does not stay saved to repeat tomorrow with a single gesture.
Content at scale. Searching for a word inside thousands of text files — not their name, what they say inside — is exactly the kind of task a graphical explorer was not built for: at best it depends on an index built in the background that can be out of date; at worst, it simply does not search content at all.

find and grep, the two tools that run through this module, solve exactly those three things: they need nothing more than a terminal to exist, they combine any number of criteria in a single line, and they read the full content of thousands of files in the time it takes a cursor to blink. They are, minute for minute of practice invested, probably the two highest-return skills in this entire guide: a couple of hours to understand them well are going to save you, for life, the number of times you open a file explorer and browse folder by folder hoping to spot something by eye.

Worked example: the same question, two ways to answer it

Imagine you inherit this project from a coworker who already left the company:

unfamiliar-project/
├── config/
│   ├── database.yaml
│   └── secrets.env
├── src/
│   ├── index.js
│   └── payments.js
├── tests/
│   └── payments.test.js
├── vendor/
│   └── lodash/
│       └── index.js
└── notes.txt

You are asked something specific before pushing it to a public repository: confirm that nobody left a hand-written credential in the code.

With a graphical explorer, the path would be to open config/, look at each file one by one, open src/, do the same, decide whether it is worth entering vendor/lodash/ (a folder from an external dependency you did not even write, but that technically also has to be ruled out), and trust that your eye does not skip a single long line inside a code file. With five files like in this example, it is tedious but doable. With the fifteen thousand files any real project with dependencies actually brings, doing it thoroughly is practically impossible.

Here is the same question solved from the terminal. You do not need to understand every word yet — you learn find in depth in lesson 5 and grep in lesson 6 — for now, just look at the shape and the result:

find unfamiliar-project -name "*.env"

What to expect:

unfamiliar-project/config/secrets.env

An .env file — the extension almost any project uses for credentials — showed up immediately, with no folder opened by hand. Now you look at what is inside, and at the same time confirm whether that same credential is used anywhere else in the code:

grep -rn "API_KEY" unfamiliar-project

What to expect:

unfamiliar-project/config/secrets.env:1:API_KEY=sk-live-FAKEEXAMPLE12345
unfamiliar-project/src/payments.js:1:const STRIPE_API_KEY = process.env.API_KEY;

Two lines, in two different files, with the exact line number of each: the credential itself, inside secrets.env, and the reference to that credential inside payments.js. Neither command opened an editor or required you to know in advance which folder to search. find answered "where" — one file, out of seven; grep answered "what the content says" — two lines, out of seven full files. That is the exact boundary between lessons 5 and 6, and you are going to see this same pair of commands again, already explained in detail, once you get there.

The module's map

This module follows a deliberate order, and it is worth seeing it whole before the first line of code: first you learn to create structure, because there is nothing to break by creating empty folders; then you learn to copy, move, and delete, with the safety taught side by side with the command — that is what the warning below is about; then you learn to read entire files without leaving your terminal unusable; only with those three pieces in hand do you get to find and grep, this module's two location tools; you close with text editing directly in the terminal, and with a project that pulls it all together against a directory you have never seen.

1. Introduction: creating, finding, and reading without opening an editor    ← you are here
2. Creating files and folders: mkdir and touch
3. Copying, moving, and deleting without destroying anything
4. Reading files: cat, less, head, and tail
5. Finding files with find
6. Searching inside files with grep
7. Editing in the terminal: nano and vim survival
8. Project: audit a project you do not know

The final project (lesson 8) hands you someone else's directory, similar to the unfamiliar-project/ from the example above but much bigger and messier, and asks you exactly what you just saw: get your bearings, understand what is there, and leave it in shape — using every piece of this module, not just find and grep.

Early warning: here you really can break something

In module 1 there was not much risk: looking at a directory with ls or moving around with cd does not change anything on disk. The next lesson does not have much either — creating an empty folder with mkdir destroys nothing. But lesson 3, the one right after, introduces rm, and with rm this module crosses a line that did not exist until now: for the first time in this guide, a mistyped command can delete something forever, with no recycle bin involved and no undo button.

That is why this guide does not split "here is the command" from "here are the precautions" into two separate moments, the way many tutorials do when they show rm -rf first and add the safety warning as a footnote, if they add it at all. In lesson 3 you are going to learn the safety criteria — listing before deleting, distrusting wildcards, checking for empty variables — in the same breath you learn the command, not afterward. Keep this in mind starting now: when you get there, the temptation is going to be to copy the command and keep moving. Resist it for one more lesson; you are going to be grateful the first time you almost delete something you were not going to be able to recover.

Common mistakes

Thinking that graphical-explorer search and terminal search solve the same problem, just one with clicks and the other with text (conceptual). That is not the case: they change scale and environment, not just form. The graphical explorer works reasonably well on your own desktop, with human-sized folders and an available interface; find and grep are built for what the graphical explorer cannot do at all — combine several criteria at once, operate on thousands of files in seconds, work on a remote server with no interface whatsoever. How to spot it: if your plan for a large inherited project is still "I am going to open folders and look," it is time to remember this lesson's example. How to fix it: before opening a single folder by hand, ask yourself whether the answer is about where something is or what the content says, and pick find or grep accordingly.

Assuming the terminal has, by default, a recycle bin like the desktop's (conceptual). It is a reasonable assumption if all you knew until now was dragging files to a trash can and being able to recover them later. In the terminal, unless you install a separate tool for that — something you will see as an option in lesson 3 — it does not exist: rm deletes, and there is no second step to reconsider. How to spot it: if, thinking about deleting something through the terminal, your mental plan includes "and if I regret it, I recover it later" without having verified that is true, the assumption is unconfirmed. How to fix it: treat every delete operation in the terminal as if there were no way to undo it, until lesson 3 shows you exactly what your real options are.

Wanting to jump straight to find or grep because they are "the interesting tools," skipping creating, copying/moving/deleting, and reading files first. It is an understandable temptation: they are the two skills this module promotes most loudly, and you just saw in the example above what they can do. The problem is that lessons 2 through 4 are not filler before getting to the good part: they give you the vocabulary of files and folders you are going to build the practice trees for lessons 5 and 6 with, and the safety judgment you are going to need the moment find offers you batch deletion with -delete. How to spot it: if you find yourself copying find commands from somewhere else without being able to explain which folder you are standing in or what file would be lost if the command failed. How to fix it: respect the map's order once; for the rest of your career with the terminal you are not going to need anyone to remind you again.

Exercises

Exercise 1 — Graphical explorer or terminal. For each scenario, decide whether the graphical file explorer is enough or you need the terminal, and justify it with the three faces of the limit you saw in this lesson: interface existence, combined criteria precision, and content search at scale.

You are looking for a photo you took yesterday, in a vacation folder with twenty photos, and you roughly know what it is called.
You SSH into a remote server and need to find, among thousands of log files, which ones were modified in the last hour.
In your local project of five thousand files, you need to know which ones still use a function you are about to remove.

See solution

Graphical explorer. Twenty photos is a scale where the human eye works fine, you have an interface available on your own machine, and you do not need to combine criteria: just recognize an approximate name.
Terminal, no alternative. A remote server over SSH has no graphical interface — the first limit on the list — so the question cannot even be attempted with a file explorer. It is a case for find filtering by modification date.
Terminal. Finding where a function is used means searching inside the content of thousands of files, not by their name — the third limit. It is a job for grep, and doing it by eye across five thousand files is not viable in practice.

Why it works: the criterion is not "the terminal always wins." It is noticing which of the three limits — interface existence, combined criteria, content at scale — is present in each scenario, and that limit is exactly what the graphical explorer does not solve.

Exercise 2 — Where is it or what does it say? For each question, decide whether find (searches by metadata: name, type, size, date) or grep (searches inside content) would answer it best. You do not need to know the syntax yet — just identify the type of question.

"Which is the heaviest configuration file in this project?"
"Which file defines the calculateTotal function?"
"Which files were modified in the last 24 hours?"
"Does the word TODO show up in any comment in the project?"

See solution

find — the question is about a file property (size), not its content.
grep — you need to find where a specific piece of text (the function's name) appears in the code, with no prior knowledge of which file it lives in.
find — metadata again, this time modification date.
grep — again, searching for a word inside the files' content.

Why it works: the key question is whether the answer depends on what the file is named, how much it weighs, or when it was touched (metadata → find) or on what is written inside it (content → grep). That boundary is exactly what separates lessons 5 and 6, and recognizing it beforehand saves you from trying the wrong tool first.

Exercise 3 — Before knowing the command. You have not learned rm or its safety flags yet — they arrive in lesson 3 — but you already know, from this lesson, one central fact about it: there is no recycle bin by default. With just that fact, explain in two or three sentences what habit you would adopt before running any delete command in the terminal, even without knowing the exact syntax yet.

See solution

There is no single correct wording, but the central idea should be: before deleting something through the terminal, you have to confirm exactly what is going to be deleted — for example, by looking at it first with some command that only lists, without touching anything — and not assume there is a second chance afterward. The habit does not depend on rm's specific syntax: it depends on treating any deletion as irreversible by default, until proven otherwise.

Why it works: the fact that the terminal has no recycle bin by default is not a minor technical detail, it is the reason lesson 3 teaches safety alongside the command. Adopting the habit of verifying before deleting, even before knowing the exact syntax, is exactly the attitude that lesson is going to formalize with concrete rules.

Summary and next step

You saw why the graphical file explorer — useful on your own desktop — stops being enough the moment a project grows or lives on a remote server with no interface, and why find (locating by metadata) and grep (locating by content) are, minute for minute of practice, two of this guide's highest-return tools. You also saw the module's full map and a warning worth not forgetting: starting next lesson you begin creating, and from lesson 3 on you hold a command, rm, that can delete something forever.

Before moving on you should be able to:

Explain, in your own words, the three reasons a graphical file explorer stops being enough on a real project.
Tell whether a question about files is a "where" type (metadata, find) or a "what does it say" type (content, grep), without knowing how to write the command yet.
Name, without looking at the map, which lesson introduces this module's first command capable of destroying data, and why this guide teaches its safety alongside the command instead of afterward.

What comes next is not searching yet. Before finding something, you need to be able to create the structure you are going to practice the rest of the module on: folders and files, with mkdir and touch, including a way to create several at once that you are going to use in almost every example ahead.

Resources

find(1) — Linux manual page — full reference for find, the utility you are going to learn in depth in lesson 5.
grep(1) — Linux manual page — full reference for grep, which you are going to learn in depth in lesson 6.
GNU Findutils Manual — full reference for find, the GNU version that runs on almost any Linux distribution.
GNU Grep Manual — full reference for grep, including the recursive search options you are going to use from lesson 6's first example.
GNU Coreutils Manual — rm invocation — the official reference for the command this lesson's warning asks you to treat with respect starting now; the full detail arrives in lesson 3.

← Previous8. Project: a treasure hunt through your machine Next →2. Creating files and folders: mkdir and touch