# The Filesystem, Explained

> A filesystem is the tree of files and folders the OS lays over raw numbered storage; a path is an address into that tree, permissions decide who may touch each file, and a few simple rules explain almost every 'file not found' or 'permission denied' you'll ever hit.


---

# The Filesystem, Explained

You've saved a file and then couldn't find it. You've typed a path and gotten "no such file or directory." You've tried to edit something and been told "permission denied," with no idea what you did wrong. None of that is you being bad at computers - it's that nobody ever showed you what a filesystem actually *is*. This guide fixes that: by the end you'll picture the whole tree in your head, read any path like a street address, and know exactly why those errors happen and how to clear them.

## How to read this
- **Stuck on an error right now?** Jump to [Phase 3: Where Things Live & Finding Them](03-where-things-live.md) and use the gotcha cheat at the top - "file not found," "permission denied," and `\` vs `/` are all there.
- **Want it to finally make sense?** Read in order. Each phase builds on the last: first the tree, then who's allowed to touch it, then how the OS actually finds your stuff.

## The phases
1. **[What a Filesystem Is](01-what-a-filesystem-is.md)** - the disk is dumb numbered storage; the OS lays a tree of folders and files on top, and a path is an address into that tree.
2. **[Permissions & Ownership](02-permissions-and-ownership.md)** - every file has an owner and rules for who can read, write, or run it. This is why "permission denied" happens, and what it's protecting.
3. **[Where Things Live & Finding Them](03-where-things-live.md)** - how a path becomes real bytes, what hidden files and extensions really are, where standard things live, and how to find anything - plus a cheat for the three classic errors.

> This guide is about *navigating and understanding* the filesystem. The deeper machinery - how the disk is partitioned, what ext4 / NTFS / APFS actually do on the metal, symbolic links, and mounting drives - is deferred to a follow-up guide so this one stays a clear first map, not a manual.


---

# What a Filesystem Is

Let's build the picture first - once you have it, paths and folders stop being a maze and become a map you
can read at a glance. Forget commands for a minute; we're installing one mental model.

## The disk is just numbered storage

**What it actually is.** Down at the hardware, your disk (or SSD) has no idea what a "file" or a "folder"
is. It's a huge wall of numbered boxes, each holding a chunk of bytes - box 0, box 1, box 2, on and on,
millions of them. That's all the hardware offers: "give me a number, I'll give you back what's stored there."

```text
   THE RAW DISK (what the hardware actually is)
   ┌────┬────┬────┬────┬────┬────┬────┬────┬────┐
   │ 0  │ 1  │ 2  │ 3  │ 4  │ 5  │ 6  │ 7  │ …  │   each box = a chunk of bytes
   └────┴────┴────┴────┴────┴────┴────┴────┴────┘   no names, no folders, no order
```

**Why people get this wrong.** Most people imagine their files are literally *inside* folders, the way
papers sit inside a physical drawer, neatly grouped on the disk. They aren't. A photo might be scattered
across boxes 4,201 and 88,015 and 502,330. The tidy folders you see are not a property of the disk - they're
a story the operating system tells *on top of* those numbered boxes.

📝 **Terminology.** A *filesystem* is exactly that story: the system the OS uses to turn dumb numbered
storage into named files organized in folders, and to remember which boxes belong to which file. (If "the
OS" is fuzzy, [What an Operating System Is](/guides/what-an-operating-system-is) covers the manager-in-the-
middle idea.)

## The OS lays a tree on top

**What it actually is.** The filesystem organizes everything into a **tree**: folders that contain files and other folders, branching down from a single starting point. A *folder* (also called a *directory*) is just a named container; a *file* is a named blob of bytes. That's the whole structure.

```mermaid
flowchart TD
  root["/ (root)"] --> home[home/]
  root --> etc["etc/ (system config)"]
  root --> usr[usr/]
  home --> ada["ada/ (your home folder)"]
  ada --> notes[notes.txt]
  ada --> projects[projects/]
  projects --> budget[budget.xlsx]
  usr --> bin["bin/ (installed programs)"]
```

Notice there's exactly one box at the very top that everything hangs off. That's the **root**.

📝 **Terminology.** *Directory* and *folder* mean the same thing. "Folder" is the friendly desktop word; "directory" is the word the terminal and most docs use. We'll use them interchangeably.

💡 **Key point.** The disk is a flat wall of numbered boxes. The folders-and-files *tree* is a structure the OS imposes on top to make that storage usable by humans. Everything else in this guide is about navigating that tree.

## The root: the top of the tree

**What it actually is.** Every filesystem has a single starting point that contains everything else, directly or indirectly. On macOS and Linux it's written as a lone forward slash: `/`. On Windows each drive has its own root, written with a drive letter and a backslash: `C:\`, `D:\`, and so on.

Let's actually look at the root on a Mac or Linux machine. (We'll use the terminal here; if it's
unfamiliar, [The Terminal and Shell](/guides/the-terminal-and-shell) introduces it gently.)

```console
$ ls /
bin   etc   home   lib   tmp   usr   var
```
*What just happened:* `ls` means "list what's in this folder," and `/` is the root. So you asked "what sits
at the very top of the tree?" and the OS listed the top-level folders. Everything on the machine lives
somewhere underneath one of these.

⚠️ **Gotcha - Windows is different here.** Windows doesn't have one single root. Each storage device gets
its own letter, so there's a `C:\` tree (usually your main drive), and a USB stick might show up as `E:\`
with its *own* separate tree. The equivalent peek:

```console
C:\> dir C:\
 Directory of C:\

 Program Files
 Users
 Windows
```
*What just happened:* `dir` is the Windows version of `ls`, and `C:\` is the root of the C drive. Same idea
as `/` - the top of one tree - but Windows has one tree per drive, not one tree for the whole machine.

## A path is an address

**What it actually is.** A *path* is the route from somewhere to one specific file, written as a list of
folder names separated by slashes - a street address (country, city, street, house number), except it's
root, folder, subfolder, filename.

Read this path left to right:

```text
   /home/ada/projects/budget.xlsx
   │  │    │   │        └── the file we want
   │  │    │   └── inside a folder called "projects"
   │  │    └── inside ada's home folder
   │  └── inside the "home" folder
   └── starting at the root
```

📝 **Terminology.** macOS and Linux separate folders with a **forward slash** `/`. Windows traditionally uses a **backslash** `\`, so the same kind of path looks like `C:\Users\ada\projects\budget.xlsx`. Same concept, different separator - and this difference causes real confusion, which is why we name it now.

## Absolute vs relative paths

This is the one distinction that clears up most "but I typed the right path!" frustration.

**An absolute path** starts at the root and gives the complete address, so it means the same file no matter
where you currently are. You can spot it because it begins with `/` (or `C:\` on Windows):

```console
$ cat /home/ada/notes.txt
Buy milk. Call the bank. Finish the budget.
```
*What just happened:* `cat` prints a file's contents. Because the path started at `/`, it's a full address
- this finds the exact same `notes.txt` whether you run it from your home folder, the desktop, or anywhere
else.

**A relative path** starts from wherever you happen to be standing right now (your *current directory*) and
gives directions from there. It does *not* begin with a slash:

```console
$ cd /home/ada
$ cat notes.txt
Buy milk. Call the bank. Finish the budget.
```
*What just happened:* `cd` ("change directory") moved you into `/home/ada`. Now `notes.txt` - with no
leading slash - means "`notes.txt` starting from where I am," which resolves to `/home/ada/notes.txt`. Same
file, shorter address, because you were standing in the right place.

📝 **Terminology.** Two special relative names show up everywhere: `.` means "the folder I'm in right now," and `..` means "the folder one level up." So `cd ..` walks you up toward the root, and `../photos/cat.jpg` means "go up one, then into photos."

⚠️ **Gotcha.** A relative path that works in one place fails in another, and the error looks identical to a
typo. If `cat notes.txt` says "no such file," you're probably not standing where you think you are. Run
`pwd` ("print working directory") to ask the OS where you currently are:

```console
$ pwd
/home/ada/projects
```
*What just happened:* You asked "where am I?" and got the absolute path of your current folder. From `/home/ada/projects`, the relative name `notes.txt` points at `/home/ada/projects/notes.txt` - which doesn't exist. That's the whole mystery: the path was fine, your location wasn't.

## The home folder and `~`

**What it actually is.** Your *home folder* is the one folder that belongs to you - where your documents,
desktop, and personal settings live. Every user account gets its own. On Linux it's usually
`/home/yourname`, on macOS `/Users/yourname`, on Windows `C:\Users\yourname`.

Because you refer to your home folder constantly, Unix-style shells give it a one-character nickname: the
tilde, `~`.

```console
$ cd ~
$ pwd
/home/ada
```
*What just happened:* `~` expanded to your home folder's full path, so `cd ~` took you home. `~/projects/budget.xlsx` is just shorthand for `/home/ada/projects/budget.xlsx`. Typing `cd` with no path at all usually does the same thing - drops you at home.

💡 **Key point.** `~` is not a folder named "tilde." It's a shorthand the shell replaces with the absolute path of *your* home folder. Two different users typing `~` get two different real paths.

## Recap

1. The **disk** is dumb numbered storage; the **filesystem** is the tree of folders and files the OS imposes on top of it.
2. The **root** is the single top of the tree - `/` on macOS/Linux, and one per drive (`C:\`, `D:\`) on Windows.
3. A **path** is an address built from folder names: forward slashes on Unix, backslashes on Windows.
4. **Absolute** paths start at the root and mean the same file everywhere; **relative** paths start from where you're standing - so `pwd` is your best friend when a path "should" work but doesn't.
5. Your **home folder** is your personal space, nicknamed `~` in the shell.

Next, we'll look at why the tree won't always let you in - the rules of ownership and permission that decide who can read, change, or run each file.


---

# Permissions & Ownership

Sooner or later the filesystem tells you "permission denied," and it feels like the computer is being
difficult on purpose. It isn't. Every file carries rules about who's allowed to touch it, and once you can
read those rules, that error stops being a wall and becomes a clear, fixable message.

## Why permissions exist at all

**What it actually is.** A shared computer holds things that shouldn't be freely editable by everyone: the
system's own configuration, other users' private files, the programs that keep the machine running.
Permissions are the filesystem's answer to a question asked on *every single file access*: "is this person
allowed to do this?"

**Why this matters.** Without permissions, any program you ran - or any other user on the machine - could
overwrite the OS, read your private documents, or delete someone else's work. "Permission denied" is usually
the system doing its job: stopping a mistake or a security hole.

💡 **Key point.** "Permission denied" is not a bug and rarely a glitch. It means: *the rules on this file don't grant you what you just tried to do.* The fix is always one of three things - do it as a user who's allowed, change the file's rules, or accept that you shouldn't be doing it.

## The two questions: who owns it, and who can do what

Every file answers two things. First, **who owns it** - on Unix systems that's an *owner* (one user) and a *group* (a named set of users). Second, **what's allowed**, broken into three actions for three audiences.

The three actions:

```text
   r  = read     → look at the file's contents (or list a folder's contents)
   w  = write    → change the file (or add/remove things in a folder)
   x  = execute  → run the file as a program (or enter/pass through a folder)
```

The three audiences, in order:

```text
   user    → the single owner of the file
   group   → everyone in the file's group
   others  → everybody else on the machine
```

📝 **Terminology.** This is the **rwx model**: read / write / execute, granted separately to **user, group, and others**. Almost every permission question on macOS and Linux comes down to reading this little grid.

## Reading `ls -l` - the permission line decoded

**What it does in real life.** Add `-l` ("long" format) to `ls` and the filesystem shows you the rules. Here's the line that confuses everyone the first time, fully annotated:

```console
$ ls -l notes.txt
-rw-r--r--  1  ada  staff  1048  Jun 19 09:14  notes.txt
```
*What just happened:* you asked for the detailed listing of one file. That cryptic `-rw-r--r--` is the
permission grid, and `ada` / `staff` are the owner and group. Here's how to read it:

```text
   -  rw-  r--  r--   1   ada   staff   1048   Jun 19 09:14   notes.txt
   │  │    │    │          │     │       │      │              │
   │  │    │    │          │     │       │      │              └ file name
   │  │    │    │          │     │       │      └ last modified
   │  │    │    │          │     │       └ size in bytes
   │  │    │    │          │     └ group that owns it
   │  │    │    │          └ user who owns it
   │  │    │    └ OTHERS can: read only (r--)
   │  │    └ GROUP can: read only (r--)
   │  └ USER (ada) can: read and write (rw-), but not execute
   └ type: "-" = file, "d" = directory
```

In plain English: `ada` can read and edit this file; everyone else can only read it; nobody can run it as a
program (it's text, not a program - `x` is off everywhere). That single line answers "why can't my coworker
edit this?" before they even ask.

Now a folder and a program for contrast:

```console
$ ls -l
drwxr-xr-x  4  ada  staff   128  Jun 18 17:02  projects
-rwxr-xr-x  1  ada  staff  9216  Jun 10 11:30  deploy.sh
```
*What just happened:* the leading `d` on `projects` marks it a directory, and its `x` bits mean people are
allowed to *enter* it (for folders, `x` means "pass through," not "run"). `deploy.sh` has `x` set for
everyone, so it's a file meant to be run as a program - what makes a script executable.

⚠️ **Gotcha - `x` means different things for files and folders.** On a *file*, `x` = "run this as a
program." On a *folder*, `x` = "you may enter it." A folder you can read (`r`) but not enter (`x`) will let
you see the names inside but not open them - baffling until you know this rule.

## "Permission denied" - what it really means

**What it does in real life.** Here's the error in the wild, and the calm read of it:

```console
$ echo "edit" >> /etc/hosts
bash: /etc/hosts: Permission denied
```
*What just happened:* you tried to *write* to `/etc/hosts`, a system file owned by the administrator. Your
user has read but not write permission on it, so the filesystem refused before changing a single byte.
Nothing broke - the rule held.

The straight fix on Unix is to act as the administrator for that one command using `sudo` ("do this as the
superuser"). To actually change a system file, open it as the administrator - for example with a terminal
editor:

```console
$ sudo nano /etc/hosts
[sudo] password for ada:
```
*What just happened:* `sudo` asked for your password and, because you're allowed to use it, opened
`/etc/hosts` as the administrator - who *does* have write permission. `sudo` runs one command with full
rights; that's how you cross the permission line on purpose. (Why not `sudo echo "edit" >> /etc/hosts`? The
`>>` redirect is handled by your *shell*, running as you, *before* `sudo` ever starts - so it still hits
"permission denied." Editing the file as above sidesteps the trap.)

⚠️ **Gotcha.** Reflexively slapping `sudo` on everything to make errors disappear is how people accidentally
damage their system or end up owning files as `root` that they can no longer edit normally. If a normal
action needs `sudo`, pause and ask *why* this file is protected before forcing past it.

## Changing the rules: `chmod` and `chown`

**What it actually is.** `chmod` ("change mode") edits the rwx rules; `chown` ("change owner") changes who owns the file. You mostly reach for `chmod` to make a script runnable:

```console
$ chmod +x deploy.sh
$ ls -l deploy.sh
-rwxr-xr-x  1  ada  staff  9216  Jun 10 11:30  deploy.sh
```
*What just happened:* `chmod +x` turned on the execute bit. Before, the file was just text the system wouldn't run; now the `x`s are present and you can run it as a program. This is the single most common reason a beginner reaches for `chmod` - "permission denied" when trying to run their own script.

## A short note on Windows

Windows reaches the same goal - controlling who can do what - by a different, more detailed road called
**ACLs** (Access Control Lists). Instead of three audiences (user/group/others) with three bits each, an
ACL is a *list* of entries, each naming a specific user or group and spelling out exactly what they may do
(read, write, modify, full control, and more).

📝 **Terminology.** An *ACL* is a per-file list of "who → what they're allowed." It's more granular than
Unix rwx, which is why Windows permissions are usually managed through the file's **Properties → Security**
dialog rather than a single readable line. The mental model is identical: a file knows its owner, and it
knows the rules for who may touch it.

## Recap

1. Permissions exist to **safely share one machine** - they answer "is this person allowed to do this?" on every file access.
2. Unix files carry an **owner** and **group**, plus **rwx** (read / write / execute) for **user, group, and others**.
3. `ls -l` shows the rules; read the line left to right - type, then three triplets of rwx.
4. **`x` means "run" on a file but "enter" on a folder** - a classic source of confusion.
5. **"Permission denied"** means the rules didn't grant your action; cross the line *on purpose* with `sudo` (carefully), or change the rules with `chmod` / `chown`.
6. **Windows uses ACLs** for the same idea - more detailed lists, same goal.

Next, we'll connect the tree and the rules to what actually happens when you open a file - plus hidden files, what extensions really are, and how to find anything on the disk.

## Try it yourself

Toggle the permission bits and watch the octal (e.g. `755`) and `rwx` string update:

```playground-chmod
```


---

# Where Things Live & Finding Them

You can now picture the tree and read the rules. This last phase ties it together: what *actually happens*
when you open a file, the two naming conventions everyone misreads as magic, where to expect standard
things, and how to find anything you've misplaced. We'll start with the cheat-card, since you might be here
mid-panic.

## Cheat: the three errors that bite everyone

| Symptom | What it usually means | Calm fix |
|---|---|---|
| `No such file or directory` | You're not standing where you think, or there's a typo | `pwd` to confirm where you are; check spelling and case; try the **absolute** path from `/` |
| `Permission denied` | The file's rules don't grant your action (see [Phase 2](02-permissions-and-ownership.md)) | `ls -l` to read the rules; run as an allowed user (`sudo`, carefully) or `chmod` it |
| Path "works" on one OS, not the other | `\` vs `/` mismatch, or a drive letter | Unix uses `/`; Windows uses `\` and drive letters like `C:\` - don't copy a path across as-is |

Each row is explained in full below.

## How a path becomes real bytes

**What it actually is.** When you open `/home/ada/notes.txt`, the OS doesn't magically know where the bytes
are. It *walks the tree*: looks up `home` in the root, finds `ada` inside `home`, finds `notes.txt` inside
`ada`, and only then learns which numbered boxes on the disk hold the contents. Each step also checks
permissions - that's why a folder you can't enter (`x` off) blocks everything beneath it.

```mermaid
flowchart LR
  root["/"] -->|look up home| home[home]
  home -->|look up ada| ada[ada]
  ada -->|look up notes.txt| entry[notes.txt entry<br/>records which disk boxes hold the bytes]
  entry --> bytes[Read the bytes]
```

💡 **Key point.** A path is resolved one folder at a time, top down, checking permission at each step. This is why "no such file" can mean a folder *partway up* the path is wrong, and why "permission denied" can come from a folder you didn't even name - you lacked `x` to pass *through* it.

📝 **Terminology.** The disk entry that records a file's real location and its rwx rules is called an
*inode* on Unix systems. You rarely touch it directly; the name is worth knowing because it's why a single
file can sometimes appear under two names (two directory entries pointing at one inode).

## Hidden files are a naming convention, not a security feature

**What it actually is.** On macOS and Linux, any file or folder whose name **starts with a dot** is hidden from normal listings. That's the entire rule. `.bashrc`, `.git`, `.env` - all hidden, all the time, for one reason: the leading `.`.

```console
$ ls
notes.txt   projects

$ ls -a
.          ..          .bashrc     .config     notes.txt   projects
```
*What just happened:* plain `ls` skipped anything starting with a dot. Adding `-a` ("all") revealed them -
your shell config (`.bashrc`), a settings folder (`.config`), and the special `.` and `..` entries. The
files were always there; they were just filtered from the default view.

📝 **Terminology.** These are called *dotfiles*. They hold configuration and tool state - the stuff you
don't want cluttering everyday listings but that programs read constantly.

⚠️ **Gotcha.** Hidden does *not* mean protected. A dotfile is fully readable and editable if its permissions
allow it (Phase 2 still applies) - the dot only hides it from casual listing, it's tidiness, not security.
On Windows, "hidden" is a separate file *attribute* you toggle, not a naming rule.

## File extensions are a hint, not magic

**What it actually is.** The `.txt`, `.jpg`, `.pdf` at the end of a name is part of the **name** - a convention so humans and programs can guess what's inside. The OS does not enforce that a `.jpg` contains an image. Rename `photo.jpg` to `photo.txt` and the bytes don't change one bit; you've only changed the label.

```console
$ mv report.pdf report.txt
$ file report.txt
report.txt: PDF document, version 1.7
```
*What just happened:* `mv` renamed the file (extension and all). But `file` inspects the *actual bytes* and
correctly reports it's still a PDF - the extension lied, the content didn't.

💡 **Key point.** Renaming a file's extension never converts it. It changes which program tries to open it
(and whether that program then chokes), but the contents are untouched. To truly convert a file you need a
program that reads one format and writes another.

⚠️ **Gotcha - Windows hides extensions by default.** Windows Explorer often hides known extensions, so
`invoice.pdf` may display as just `invoice`, and a malicious `invoice.pdf.exe` shows as `invoice.pdf` -
hiding that it's actually a program. Turning on "show file extensions" in Explorer's View settings is a
small, real security habit.

## Where standard things live

You don't have to memorize the whole tree, but a few landmarks save constant hunting. These are conventions, not laws, but they hold across most systems:

```text
   UNIX (macOS / Linux)
   /home/you  or  /Users/you   your stuff (home folder, the "~")
   /etc                        system-wide configuration files
   /usr/bin, /bin              installed programs (commands you run)
   /tmp                        temporary scratch space, often wiped on reboot
   /var/log                    log files - where to look when something failed

   WINDOWS
   C:\Users\you                your stuff (Documents, Desktop, Downloads)
   C:\Program Files            installed applications
   C:\Windows                  the OS itself - generally do not touch
```

The one worth internalizing: **`/var/log` (Unix) is where you look when a program misbehaved.** When the sibling guide [Processes, Memory & CPU](/guides/processes-memory-and-cpu) talks about a service that "won't start," its log under `/var/log` is usually the first place the answer is hiding.

## Finding things

When you don't know where a file is, you ask the filesystem to walk the tree and match names for you. On
Unix that's `find`:

```console
$ find ~ -name "budget.xlsx"
/home/ada/projects/budget.xlsx
/home/ada/old/2024/budget.xlsx
```
*What just happened:* `find ~` started at your home folder and searched every folder beneath it;
`-name "budget.xlsx"` kept only entries with that exact name. It found two - including one you'd forgotten
in an `old` folder. `find` walks the tree the same way the OS resolves a path, just visiting every branch
instead of one.

You can match patterns with `*` (meaning "any characters"):

```console
$ find . -name "*.log"
./app.log
./logs/error.log
```
*What just happened:* starting from `.` (the current folder), this found every name ending in `.log` at any
depth. The `*` is a wildcard - "anything here" - so `*.log` means "any name that ends in `.log`."

⚠️ **Gotcha.** Running `find /` (from the root) searches the *entire* machine and will throw "Permission
denied" lines for folders you can't enter - that's Phase 2 in action, not a failure of the command. Search
from `~` or a specific folder unless you genuinely need the whole disk. (On Windows,
`dir /s /b C:\Users\you\*.xlsx` is the rough equivalent, and the desktop search box does the same job.)

## The three errors, explained

Now the cheat-card rows make full sense:

- **`No such file or directory`** - the tree-walk failed at some step. A folder name partway up was wrong,
  you're not standing where you assumed (run `pwd`), or it's a typo - and Unix paths are **case-sensitive**,
  so `Notes.txt` and `notes.txt` are different files. When in doubt, give the full absolute path from `/`.
- **`Permission denied`** - a permission check failed during the walk (Phase 2). `ls -l` the file *and* the
  folders leading to it; you may lack `x` on a folder you have to pass through. Fix by acting as an allowed
  user or adjusting the rules - on purpose, not reflexively.
- **`\` vs `/` mismatch** - a path copied from a Windows machine into a Unix shell (or the reverse) breaks
  because the separators and drive letters don't translate. Rebuild paths in the target system's style.

## Recap

1. The OS resolves a path by **walking the tree top-down**, checking permission at each folder - which explains *both* classic errors.
2. **Dotfiles** (names starting with `.`) are hidden by a naming convention, not protected; `ls -a` reveals them.
3. **Extensions** are a naming hint, not magic - renaming `.pdf` to `.txt` changes the label, never the bytes.
4. A few **standard locations** (`~`, `/etc`, `/var/log`, `C:\Users`) save you constant hunting; logs are where failures explain themselves.
5. **`find`** walks the tree to locate files by name or pattern; search from `~`, not `/`, to avoid noise.
6. The three biting errors - **not found, denied, and `\` vs `/`** - are all explainable by the model you now hold.

That's the whole map: numbered storage at the bottom, a tree on top, rules guarding each branch, and a handful of conventions for finding your way. You can read a path, read a permission line, and read an error - which is most of what "knowing the filesystem" actually means.

## Try it yourself

Poke around a fake filesystem - `ls`, `cd`, `pwd`, `cat`, `tree`. Nothing leaves your browser:

```playground-terminal
```