The window where you talk to the operating system — one line at a time. Everything you'll ever run, deploy or debug starts here.
← / → to navigate · EN/VI switch below
A text window where you talk to the OS one line at a time — no buttons, no mouse.
A line of text + Enter = a command. The OS does exactly what you asked, then prints the result.
The shell (bash, zsh) reads your line and tells the OS what to do. The terminal is just the window that shows it.
cd, ls, grep — a handful of short words that compose into anything. AI writes the long ones for you.
No undo, no 'are you sure?' — the OS does what you typed. Precision is the skill.
Every command starts with the prompt: who you are, which machine, and the folder you're standing in.
Everything on a server is a file, organized in folders that nest like tree branches. You're always standing in one of them.
A path is just an address. '/' is the root of the tree; a path is a walk down it.
/home/student ← your home folder
├── projects
│ └── app
│ ├── index.py
│ └── config.yml
├── notes
│ └── ideas.md
└── .ssh ← dotfolder (hidden)
/home/student/projects/app ← absolute: full address from /
projects/app ← relative: from where you standAbsolute paths start at the root; relative paths start where you stand.
Two ways to point at the same file. Absolute never lies; relative is shorter but depends on where you stand.
Starts at /: /home/student/notes/ideas.md. Works no matter where you're standing.
notes/ideas.md means 'the notes folder next to where I'm standing right now'.
The tilde is shorthand for /home/<you>. ~/notes saves you typing the full address.
Relative for quick local work; absolute when it must work from anywhere (configs, scripts).
The names are shortened English words — that's the trick to remembering them: pwd = print working directory, cd = change directory, ls = list.
pwd after every step — watch the address change. That's the whole skill: always know where you are.
The shell keeps one pointer: the folder you're standing in. Most commands act on it by default.
. = stay, .. = up one level, ~ = home, / = the root. That's all the movement you need.
Type notes.md and the shell looks in your current folder — no full address needed.
You're not 'running a program on a server' — you're a person walking through folders, opening doors as you go.
Lost? pwd tells you exactly where you are. It's the most retyped command in existence.
Five verbs cover nearly all file work — and again, the names are the clue: make, touch, copy, move, remove.
A complete file-management session — that's the whole toolkit.
The classic mix-up: after mv the original is gone. After cp it's still there.
cp a b → both a and b exist. The original survives; b is an independent clone (edit one, the other is untouched).
mv a b → only b exists. The original is gone. mv is also your rename command: mv old.html new.html.
Same verbs, folder superpowers: -p builds nested paths, -r copies whole folders, and mv can drop a file into a folder.
There is no trash bin on a server. The command you type is the last word.
rm deletes data immediately and for good. There is no 'restore' button.
With -r it eats folders and everything inside, recursively. One typo far from home is expensive.
Pause, read the command out loud, check the path. Your fingers are faster than your judgment.
The -i flag makes rm ask 'really?' before each delete. A great habit while you're learning.
The terminal's daily job: peek inside files and watch programs write their logs.
The names are the mnemonic: head and tail are the two ends of a file. cat for small, tail for fresh, grep to find.
| Command | Why it's named that — and what it gives you |
|---|---|
| cat file | 'concatenate' — it prints the whole file, top to bottom. For short files. |
| head file | 'the head' — the first 10 lines. What does the file start with? |
| tail file | 'the tail' — the last 10 lines, where the newest stuff lives. |
| tail -f file | Live mode: new lines print as they appear. This is how you watch logs. |
| grep err file | Search — keeps only lines containing 'err'. From 'get regular expression'. |
| less file | 'less' — page through a big file with the arrows; q quits. |
Your shipper superpower: open tail -f on a log and every new line appears the moment it's written. Ctrl-C to stop.
When something breaks, you don't read 10,000 lines — you take the last 20, then grep the ones that hurt.
Almost every 'it's broken' in this course gets solved with this exact loop.
tail -f on the log before you change anything. See what the app is actually doing.
Trigger the error (click the button, send the request) and watch the log line appear live.
Ctrl-C, then grep the log for the error: grep 500 access.log. Isolate the bad lines.
Change the code (AI helps), restart, tail -f again — the 500 is gone, 200s roll in.
The mental model only: how a command's output flows into the next command — or into a file.
One idea: every command prints text, and these four symbols steer that text somewhere useful. Watch it happen on the next slides.
cmd1 | cmd2 — cmd1's output becomes cmd2's input. The daily pattern: cat file | grep word.
ls > out.txt — capture the output in a file (overwrites whatever was there).
ls >> out.txt — add to the end without erasing. This is how logs grow.
Commands print errors on a separate channel. 2> err.log captures just the errors.
Every command prints text; | hands that text to the next command. The classic pattern: cat file | grep word.
Before pipes, chaining meant juggling temp files. The pipe deletes the middle step.
Each pipe hands text to the next command. Three tools in a row, and you've written a query — no programming needed.
Arrows point where the text goes: > writes (and overwrites), >> appends, and 2> catches the error channel.
How the machine works under your fingers — and where this window takes you in the rest of the course.
A 30-second tour of the machinery behind every command.
ls, git, docker — each is a tiny executable file somewhere on disk. You're just asking the OS to run it.
A list of folders the shell searches. That's why you can type git instead of /usr/bin/git — from anywhere.
stdout = results, stderr = errors. That's exactly why 2> exists — you can grab the errors alone.
Every command ends with an exit code: 0 = all good, anything else = it failed. You (and scripts) check it.
There is no second door into the machine. Every 'tool' you'll ever use is just a command you run in this window.
…are all just commands in your terminal. Same window, same prompt, same one-line-at-a-time rhythm.
Every future day — containers, web servers, HTTPS — is you typing a few lines here and reading the result.
You'll paste commands AI gives you. The skill is knowing what each line is for — and spotting when the output lies.
The terminal never hides its work: it prints what happened. Learn to read it and nothing surprises you.
You'll meet these on the coming days — every one of them is just a command in this same window.
| Command | Job in this course |
|---|---|
| docker compose up -d | Bring up the whole stack (app, database…) as containers. |
| nginx -t | Check the config is valid before you reload it. |
| git pull | Fetch the latest code from your repo. |
| curl http://localhost/ | Ask your own server for a page — the fastest 'is it alive?' test. |
| systemctl status nginx | Is the service running? Since when? What is it doing? |
Open a terminal, type pwd, and go walking. Every tool in this course lives inside that window.