What an operating system does

Starts from zero. This is the very beginning.

A computer, underneath everything, is just hardware: a chip that does math really fast, memory that holds numbers, a disk that stores your stuff, a screen, a keyboard, a network card. On its own, all of that does... nothing. It's like a workshop full of tools with nobody in it. Something has to pick up the tools, and something has to make sure two people don't grab the same hammer at the same time.

That something is the operating system. It's the layer that sits between your programs and the metal. When your game wants to save your progress, or your browser wants to show a picture, or a song wants to come out of the speaker, the program doesn't touch the disk or the speaker itself. It asks the operating system, and the operating system does it and hands back the result.

Think of it like the manager of a big apartment building. You live there, but you don't run your own water pipes or wire your own electricity. You flip a switch, and the building's manager has quietly handled all the plumbing behind the wall... and made sure your neighbor can't wander into your apartment while they're at it.

The heart of the operating system is the kernel. It's the part that's always running, closest to the hardware, and it never takes a break. It does a few jobs the whole time the computer is on: it shares the chip between every running program so each one gets a turn (that's why everything feels like it's happening at once), it hands out memory and keeps each program in its own space so one can't scribble on another, and it talks to the devices... keyboard, screen, disk... through little translators called drivers.

You never actually see the kernel, and that's the whole point. A program quietly asks for something, the kernel does it, and life goes on. When people say the word "Linux," the kernel is the part that literally is Linux. Everything else is built around it... which is exactly what the next lesson is about.

What Linux is, and what a "distribution" is

Builds on 1.1.

Here's a surprise: strictly speaking, Linux is just the kernel... that busy manager from the last lesson, and nothing else. And a kernel all by itself isn't something you can sit down and use. It needs a way to type commands, a set of tools, a way to install new software, usually a desktop to click around in. All of that has to be gathered up and packaged together.

That package is called a distribution, or "distro" for short. So Ubuntu, Debian, Arch and Fedora are all "Linux" because they share the exact same kind of engine underneath... but they differ in what's wrapped around it and how it's all put together.

Distros differ in mostly three ways. First, how you get new software. Each one has a "package manager" that installs programs from its own big collection... the Ubuntu family uses one called apt, Arch uses pacman, Fedora uses dnf. Second, how new versus how steady. Some distros give you the very newest versions the day they come out, others freeze a tested set and change slowly, trading shiny-and-new for rock-solid. Third, how much is decided for you. Some hand you a finished desktop with everything ready; others hand you a bare system and let you build it up piece by piece.

One shortcut: families matter more than names. Ubuntu is built on top of Debian, so almost everything you learn on one works on the other. A lot of smaller distros are really just Ubuntu with a different coat of paint. Learn one family and you're most of the way to all its cousins.

Getting a shell

Builds on 1.1 and 1.2. This is where you finally get your hands on it.

There are two ways to tell a computer what to do: you can point and click, or you can type a command. The shell is the type-a-command way. It's a program that waits for you to type an instruction, runs it, shows you what happened, and then waits again.

The terminal is just the window the shell lives inside. Terminal = the glass. Shell = the voice behind the glass. People mix the two words up all the time, but that's the real split. And here's the friendly part: it's a conversation. You type a line, press Enter, the computer does the thing and answers, and then it's your turn again. Nothing happens until you press Enter... the shell politely waits for you to finish your sentence.

When the shell is ready for you, it prints a prompt and just sits there waiting. Read it left to right: your username, then the machine's name, then where you are in the files (the ~ means your home folder... much more on that in Module 2), and finally a symbol that means "your turn." That symbol is usually a $. If you ever see a # there instead, it means you're acting as root... the all-powerful admin, the building manager holding the master key. That's powerful and a little dangerous, so we save it for Module 5.

You type, you press Enter, the shell runs your command and prints whatever it has to say, then shows the prompt again. And here's a habit worth learning early: if a command works but has nothing to report, it often says nothing at all and just gives you a fresh prompt. In this world, silence usually means success.

Open your terminal and try these one at a time, pressing Enter after each. Watch how the last two prove the first two lessons, straight from your own machine:

See it? uname told you the kernel is Linux, and os-release told you which distribution is wrapped around it. The two ideas from the last two lessons, confirmed by the machine itself.

The single tree

Builds on Module 1.

If you've used Windows, you know drives get letters... C:, D:, a USB stick becomes E:. Linux doesn't do that. There is one tree, and it starts at a single point called the root, written as just a forward slash: /. Every single file, every folder, every disk, every device... all of it hangs somewhere off that one tree. Plug in a USB stick and it doesn't become a new drive letter. It shows up as a folder somewhere in the same tree (we say it gets "mounted").

Picture an upside-down tree. The root / is the trunk at the very top, and everything branches downward from there. There's exactly one trunk, and every leaf can be reached by following branches down from it.

Off the root hang a handful of branches that are nearly the same on every Linux system. /home holds everyone's personal folders (yours is /home/yourname). /etc holds settings. /usr and /bin hold installed programs and core commands. /dev holds the devices (much more on that in 2.3). /var holds things that keep changing, like logs. A spot in the tree is named by its path... start at / and follow the branches, like /home/sam/notes.txt. Because there's only one tree, there's exactly one way to name any spot.

Navigating

Builds on 2.1.

At any moment you're standing in one spot in the tree, called your working directory. Three little commands are your feet and eyes. pwd asks "where am I?" ls asks "what's here?" cd says "go there." That's most of moving around Linux, right there.

Think of walking through a building. pwd reads the sign that says which room you're in, ls looks around the room, and cd walks you through a door into another one.

pwd prints your current spot, like /home/sam. ls lists what's in it. cd moves you. There are two ways to say where to go. An absolute path starts at the root / and gives the whole route, so cd /etc lands you in /etc no matter where you were. A relative path starts from where you already are, so cd Documents steps into the Documents folder inside your current spot. Three handy shorthands: . means "here", .. means "one level up" (cd .. steps back toward the root), and ~ means your home folder... cd with nothing at all also takes you home from anywhere.

Everything is a file

Builds on 2.1 and 2.2.

Here's Linux's founding trick. Nearly everything the system exposes... a note you typed, a folder, a hard disk, your keyboard, even information straight from the kernel... is handed to you as a file: a named thing you can open, read bytes from, and write bytes to. So instead of a different tool for every kind of thing, you learn one small set of verbs and they work almost everywhere. One universal socket, not fifty different adapters.

Everything hangs off the single tree from 2.1, and among the ordinary files are special ones that aren't stored bytes at all. /dev/sda is a whole disk. /dev/null is a sink that swallows anything you write to it. /proc and /sys are live windows the kernel opens onto itself and the hardware. When you "read" /proc/cpuinfo, nothing was sitting on a disk waiting... the kernel generates the answer the instant you ask and hands it back through the file interface. Same verb, wildly different thing behind it.

Processes are files too

Builds on 2.3. The payoff of "everything is a file."

A running program is called a process, and each one gets a number when it starts... its PID (process ID). Now the magic from the last lesson pays off: a running program isn't hidden away inside the machine. Linux shows each one as a folder under /proc, named by its PID. So you can peek inside a live, running program the exact same way you look at a file.

Under /proc/<pid>/ sit live files describing that one process: status (is it running, how much memory), cmdline (the command that started it), fd/ (the files it currently has open). Like /proc/cpuinfo, these are made live, not stored. The command ps lists the processes running near you and their PIDs. And there's a lovely shortcut: $$ is the shell's own PID, so the shell can literally read itself as a file.

Looking inside files

Builds on Module 2.

You can find your way around now. Next: look inside a file straight from the shell. Four small tools, each for a different job. cat dumps the whole file to the screen. less opens a scrolling window you can page through and then quit. head shows just the first lines. tail shows just the last lines.

Picture a long roll of paper. cat unrolls the whole thing on the floor at once. less holds a window over it that you slide up and down. head peeks at the top, tail at the bottom.

cat file prints the whole thing... perfect for short files, a firehose for long ones. less file opens a pager: arrow keys or space to move, /word to search, and q to quit. It only views, it never changes anything. head file shows the first 10 lines (head -n 3 for three); tail file shows the last 10 (tail -n 20 for twenty). One extra-handy trick: tail -f keeps a file open and prints new lines as they arrive... it's how people watch a log update live.

Making and moving

Builds on 3.1.

Now you make and rearrange things. touch creates an empty file. mkdir makes a folder. cp copies. mv moves or renames (same command, because both just mean "give this thing a new path"). And rm deletes. Here's the one to burn into memory: rm has no undo and no Recycle Bin. Gone is gone.

Think of it physically. cp is a photocopy... the original stays and you get a duplicate. mv is carrying the thing to another room, or slapping a new label on it... nothing is left behind. rm is the shredder, and there's no bin to fish it back out of.

touch notes.txt makes an empty file. mkdir project makes a folder, and mkdir -p a/b/c makes a whole chain at once. cp file copy.txt duplicates a file; cp -r folder folder2 copies a folder and everything in it. mv old.txt new.txt renames; mv file.txt project/ moves it into a folder. rm file.txt deletes a file; rm -r folder deletes a folder and all its contents. That -r ("recursive") is exactly the flag that makes rm something to type slowly.

Finding things

Builds on 3.2.

When you don't know where something is, find hunts for it. You point it at a spot in the tree and it walks every branch from there downward, printing the full path of everything that matches. Point it at a branch and say "search everything from here down."

The shape is find <where> <what>. find . -name "*.txt" means "from here (.) down, every file ending in .txt." find /home -name "notes.txt" searches all of /home. It can match more than names: -type d finds only folders, -mtime -1 finds things changed in the last day, -size +100M finds things bigger than 100 MB. Quote the pattern ("*.txt") so find handles the wildcard itself... exactly why will make sense after the next lesson.

Wildcards, and the shell's best trick

Builds on 3.3. This one changes how you see every command.

A wildcard lets one command touch many files. * means "any run of characters" and ? means "any single character." But here's the secret that changes how you read every command you'll ever type: the shell replaces the wildcard with the real matching filenames before the command runs. The command never sees the *... it only ever sees the finished list.

The shell is a translator standing between you and the command. You say ls *.txt. The translator looks in the folder, swaps *.txt for the real names, and only then hands the command ls a.txt b.txt c.txt. As far as ls knows, you typed the names out yourself.

* matches any number of characters, including none: *.txt is every .txt, report* is anything starting with "report", * is everything. ? matches exactly one character: file?.txt matches file1.txt and fileA.txt, but not file10.txt. Because the shell expands first, echo *.txt just prints the names a wildcard would match... which makes it the perfect dry-run before you do anything destructive. And it's why rm *.txt is powerful: the shell hands rm every matching file at once.

Commands, arguments, options

Builds on Module 3.

You've typed a lot of commands now. Here's the secret: they all share the same grammar. There's the command (what to run), the options (how to run it... the little dash-flags), and the arguments (what to run it on). Learn to see those three parts and every new command becomes easy: just ask "what's the verb, what are the settings, what's it acting on?"

It's a sentence. The command is the verb, the options are adverbs (how to do it), and the arguments are the object (what to do it to). ls -lh /home reads as "list, in long human-friendly form, the folder /home."

The command comes first. Options start with a dash: short ones are a single letter (-l, -a), and you can bundle them (-la is the same as -l -a). Long options use two dashes and a whole word (--all, --human-readable) and read more clearly. Arguments are the things it acts on, usually files or folders. Spaces separate every part, which matters: a filename with a space in it needs quotes ("my notes.txt"), or the shell reads it as two separate arguments.

The three streams

Builds on 4.1.

Every running program comes with three channels. Standard input (stdin) is where it reads from. Standard output (stdout) is where its normal results go. Standard error (stderr) is where its complaints go... kept on a separate channel on purpose. By default, input comes from your keyboard and both outputs land on your screen, so you never notice they're separate... until you start sending them to different places, which is the next lesson.

Picture a machine with one intake chute and two output chutes: one for good product, one for scrap. Keeping the scrap chute separate means a problem never gets mixed into the good output... you can catch it on its own.

The channels even have numbers: stdin is 0, stdout is 1, stderr is 2. A program reads from stdin, writes results to stdout, and writes error messages to stderr. Normally both outputs land on your terminal, mixed together, so you don't see the seam. But because they're separate channels, you can send them to different places (next lesson): keep the results, set the errors aside, or the reverse. That separation is why a command can flash an error on your screen even while its real output is quietly flowing somewhere else.

Pipes and redirection

Builds on 4.2. This is the superpower.

Because output and input are just channels, you can re-route them. The pipe, written |, takes one program's stdout and feeds it straight into the next program's stdin. So instead of one giant do-everything tool, Linux gives you lots of small sharp tools and lets you snap them together in a row. That's the whole Unix idea, and it's genuinely where the power lives.

Think of a conveyor belt. Each little machine does one job and drops its result on the belt, which carries it to the next machine. ls lists, grep keeps the matching lines, wc -l counts them... line them up and you've built a "count the txt files" machine out of three simple parts.

cmd1 | cmd2 sends cmd1's stdout into cmd2's stdin, and you can chain as many as you like: ls | grep txt | wc -l means "list everything, keep the lines with txt, count them." To send output into a file instead of the screen, use redirection: ls > files.txt writes the list into a file (replacing whatever was there), and ls >> files.txt adds to the end instead. You can even redirect just the errors: command 2> errors.txt (remember, stderr is channel 2).

Reading the manual

Builds on 4.1 and 3.1. The skill that makes you self-sufficient.

Nobody memorizes all of this... not even the pros. The manual is built right in. man <command> opens the full manual page for any command; <command> --help gives a quick summary. The real skill isn't memorizing commands, it's learning to read their manuals... and the one line worth learning to read is the SYNOPSIS.

Every command came with its own little instruction booklet already in the box. You just have to flip it open and know how to read the first page.

man ls opens the manual for ls. It opens inside less, so you scroll with the arrows and press q to quit... exactly the pager you met in Lesson 3.1. A man page always has the same sections: NAME (a one-line summary), SYNOPSIS (how to call it), DESCRIPTION, OPTIONS, and often EXAMPLES. For a quick reminder rather than the whole booklet, most commands take --help. And if you don't even know the command's name, apropos <word> searches for commands about a topic.

Users and ownership

Builds on Module 4.

Linux was built for many people sharing one machine, so it always keeps track of who. You are a user (back in Lesson 1.3, whoami answered with your name). Every file carries an owner (a user) and a group, and before the system lets anyone touch a file, it checks who they are. That's the whole reason your files stay yours and the system's files stay safe from an accidental bump.

Remember the apartment building from Lesson 1.1? Each tenant has their own apartment (your home folder, /home/sam) and a key to it. You can't wander into a neighbor's apartment, and you certainly can't get into the building's utility room... that belongs to the manager, root, who we'll meet at the end of this module.

Each user has a name, and the system knows your identity the moment you log in. whoami prints it; id shows your user plus the groups you belong to. In the long listing from Lesson 4.1, those two names in the middle (sam sam) are the file's owner and its group. Groups let several people share access to the same thing... a "family" group, say. Your home folder is owned by you; most of the rest of the tree is owned by root and merely readable by you.

Permissions: read, write, execute

Builds on 5.1. The one string every Linux user learns to read.

Ownership (last lesson) answers "whose." Permissions answer "who's allowed to do what." There are three actions... read (r, look at it), write (w, change it), and execute (x, run it). And there are three audiences... the owner, the group, and everyone else. So every file carries nine little yes/no switches: read-write-execute for each of the three audiences. That whole cryptic -rw-r--r-- at the front of ls -l? It's just those switches, written out.

Read -rw-r--r-- left to right. The first character is the type: - for a file, d for a directory. Then three triads: owner rw- (read and write, no execute), group r-- (read only), others r-- (read only). A program or script needs the x switch or it won't run... chmod +x hello.sh flips it on. Those numbers you'll see (like 644 or 755) are just the triads written as digits, adding up r=4, w=2, x=1: so rw- is 6, r-- is 4, giving 644. On a directory, x has a special meaning: "you're allowed to enter it."

root and sudo

Builds on 5.2, and closes the foundations.

Here's a feature disguised as a limitation: as a normal user, you can't change most of the system. Almost everything outside your home is owned by root, the all-powerful admin identity... the building manager with the master key, from Lesson 1.1. That's on purpose. It means you can't accidentally wreck the machine. When you genuinely need to do an admin job... install software, edit a system file... sudo lets you borrow root's power for that one command, then hands it back.

root is the master key, and you don't carry it around... too easy to do damage. sudo is checking that key out from the front desk for a single job, signing for it with your own password, and returning it the moment the command finishes. And the # prompt from Lesson 1.3? That's the sign you're holding the key right now.

Your everyday commands run as you. A system-changing one gets refused with Permission denied, because you don't own those files. Put sudo in front to run that single command as root: sudo apt install ..., sudo nano /etc/hosts. It asks for your password (to confirm it's really you), runs the one command with full power, and then you're an ordinary user again. Full root shells exist, but people avoid living in them... running sudo one command at a time keeps every powerful action deliberate. And the prompt tells you which hat you're wearing: $ is you, # is root.

What a process really is

Builds on 2.4 (processes are files too) and 5.1 (users).

A program sitting on disk is just a file. The moment you run it, the kernel makes a process: the program's code, its own private patch of memory, a PID, and a note about who started it. That "who started it" is the interesting part. No process appears out of nowhere... every one is spawned by another process, its parent. Your shell spawned ls. Something spawned your shell. Follow the chain up and it always ends at the same place: PID 1, the very first process the kernel starts at boot (on most systems that's systemd), the ancestor of everything.

So the whole machine is one family tree. Not a pile of programs... a tree, with one root.

Each process carries its own PID and its parent's PID (the PPID). ps shows the processes in your terminal; ps -e shows every process on the machine; ps -ef adds the parent for each one. pstree draws the whole thing as an actual tree, which is the fastest way to see the idea. When a parent exits, its children are handed up to be adopted... usually by PID 1... so nobody is ever orphaned. The kernel also gives each process its own memory that no other process can touch, which is why one crashing program doesn't take the rest down with it (that's the memory-guarding job from Lesson 1.1, now visible).

Foreground, background, and jobs

Builds on 6.1 and 4.2 (the three streams).

When you run a command, the shell hands it your terminal... your keyboard and your screen... and waits. That's a foreground job: it has your attention, and the prompt doesn't come back until it's done. But the shell can also run a job in the background: it keeps running, the prompt comes straight back, and you carry on. And a job can be stopped... paused mid-flight, going nowhere until you say. Three states, and a handful of keys and commands to move a job between them.

Think of the shell as having one pair of hands. A foreground job is the thing it's holding. Putting a job in the background is setting it on the bench to keep running on its own. Stopping is pressing pause.

Run command & and it starts in the background; the shell prints a job number and a PID and gives you the prompt straight back. jobs lists your background and stopped jobs. If something's hogging the foreground, Ctrl-Z stops it (pauses, doesn't kill); then bg lets it keep running in the background, or fg brings it back to the front. A job that writes to the screen will still splatter text over your prompt from the background... send its output somewhere with > (Lesson 4.3) if that bugs you. And a plain background job dies when you close the terminal; nohup command & lets it survive the disconnect... the crude ancestor of the tmux session you'll meet in 301.

Watching the machine

Builds on 6.1.

top is a live window onto the machine, refreshing every couple of seconds: how busy the processor is, how much memory is in use, and which processes are eating the most. It's the first place to look when a box feels slow. But a screen of numbers is useless until you know what they mean... and the single most important habit is learning what normal looks like on your own machine, so an odd number stands out the moment it appears.

The load average is three numbers: how busy the machine has been over the last 1, 5, and 15 minutes. The scale is per core: on a 4-core box, 4.0 means every core fully busy, 0.4 means mostly relaxed. The CPU line splits time into user programs (us), the kernel (sy), and idle (id)... high idle is a happy machine. The memory line is total, free, and used. Below all that, the process table, busiest first by default. Press M inside top to sort by memory instead, P for CPU, and q to quit. htop is the same idea with colour and mouse support, if it's installed.

Stopping things safely

Builds on 6.1, 6.2 and 5.3 (sudo).

Despite the name, kill doesn't kill... it sends a signal, a short message the kernel delivers to a process. The everyday one is SIGTERM: "please stop." A well-behaved program catches it, finishes what it's doing, saves its work, closes its files, and exits cleanly. Only if that fails do you reach for SIGKILL (kill -9): the kernel ends the process on the spot, no message delivered, no chance to tidy up. It always works, and that's exactly why it's dangerous... half-written files and stuck locks are what you get when a program never got to say goodbye.

Think of it as the difference between knocking on a door and asking someone to leave, versus cutting the power to the building. The first is how you handle things. The second is for when the first didn't work.

kill <pid> sends SIGTERM. Give the program a few seconds to honour it. If it's truly hung and won't respond, kill -9 <pid> sends SIGKILL, which cannot be caught or ignored. pkill <name> and killall <name> target by name instead of number, which is handy and also easy to over-aim. There are other signals too: kill -HUP tells many services to re-read their config without restarting, and Ctrl-C in a terminal is just SIGINT delivered by the shell. You can only signal your own processes; stopping someone else's, or a system service, needs sudo (Lesson 5.3).

Modes by number

Builds on 5.2 (read, write, execute).

In Lesson 5.2 you learned that each audience gets three switches: read, write, execute. Here's the trick that makes them fast to type: give each switch a weight... read is 4, write is 2, execute is 1... and add up the ones that are on. rw- is 4+2 = 6. r-x is 4+1 = 5. rwx is 4+2+1 = 7. Do that for owner, group, and others, and a whole permission string collapses into three digits. rw-r--r-- is just 644. That's the entire secret behind those numbers.

chmod 644 file sets the whole string at once, which is why numbers beat the +x-style letters once you're fluent. The ones you'll reach for: 644 for ordinary files (you edit, everyone reads), 755 for scripts and folders (runnable or enterable by all), 600 for private files like keys (only you, and only read/write), 700 for a private folder. New files don't start at 777 and get trimmed by hand... a setting called the umask quietly subtracts permissions from every new file, which is why fresh files usually land at 644 and fresh folders at 755 without you doing anything.

Groups that do something

Builds on 5.1 (users and ownership) and 7.1.

Back in Lesson 5.1 every file had a group beside its owner, and the middle triad of the permission string was "what the group may do." Until now that's been a dead letter, because on a one-person machine your group is just... you. Groups earn their keep the moment two people share something. Make a group called family, put everyone in it, hand a folder to that group with rwx for the group... and now every member can create and read files there, while strangers can only look. That's the whole design: a group is a name for a set of people, so you can give permission to the set instead of one person at a time.

Making a group and filling it needs root: sudo groupadd family, then sudo usermod -aG family alex for each person (the -a means append... forget it and you replace all their groups with this one). groups or id shows who's in what. Then point a folder at the group with chgrp family /srv/shared and open it up with chmod 775 /srv/shared (or 770 to shut outsiders out entirely). The classic gotcha: group membership is read at login. Add someone to a group and their current shell doesn't know yet... they log out and back in (or run newgrp family) before it takes.

Giving things away with chown

Builds on 5.1, 5.3 (sudo) and 7.2.

chmod changes what people may do; chown changes whose the thing is. chown alex report.txt makes alex the owner. chown alex:family report.txt sets owner and group in one go. Here's the rule that surprises people: you can't give away a file you own. Only root can change who owns something. That's deliberate... if anyone could hand files to anyone, you could dump a giant file onto someone else's quota or make your mess look like theirs. So ownership changes go through sudo, on purpose.

sudo chown user file changes the owner. sudo chown user:group file changes both; sudo chown :group file changes only the group (the same as chgrp). Add -R to walk a whole folder tree... which is the flag to type slowly. sudo chown -R sam /home/sam is a normal repair after you've accidentally run something as root in your own home. sudo chown -R sam / is how you turn a working system into a paperweight in one line, because half the system only works when root owns it.

The three special bits

Builds on 7.1, 7.2 and 7.3. The strange letters in ls -l, explained.

Three extra switches sit above the nine you know, and each one solves a real problem. The sticky bit on a folder means "anyone can add files here, but only a file's owner can delete it"... that's /tmp, shared by everyone and safe anyway. The setgid bit on a folder means "every new file in here takes the folder's group, not the creator's"... the missing piece from 7.2, so files in a shared folder don't quietly fall back to each person's own group. And the setuid bit on a program means "run this as the file's owner, not as whoever launched it"... which is how passwd, owned by root, can change your password inside a root-only file while you stay a normal user.

They're written as a fourth digit in front: 1 for sticky, 2 for setgid, 4 for setuid, so /tmp is 1777 and a shared folder becomes 2775. In ls -l they replace an x: a t at the very end is sticky, an s in the group triad is setgid, an s in the owner triad is setuid (a capital S or T means the bit is set but the underlying x isn't, which is usually a mistake). Sticky and setgid on folders are everyday tools. Setuid on a program is powerful and rare... it's how passwd and sudo themselves work, and a setuid program with a bug is one of the classic ways a machine gets broken into, so you don't sprinkle it around.

One tree, many disks

Builds on 2.1 (the single tree).

In Module 2 you learned there's one tree, starting at /. Here's the part that was hidden: that tree isn't one disk. Linux takes each disk (or each slice of a disk, or a USB stick you plug in) and grafts it onto the tree at a chosen folder. That folder is called a mount point. So / might live on one disk, your /home on another, and a memory stick appears at something like /mnt/usb. To you it's still one smooth tree you walk with cd... underneath, you're stepping from one disk to another without ever noticing the seam.

Think of a big building where a few of the "rooms" are actually separate buildings joined by a hallway. You walk straight through and it feels like one place. Mounting is joining a new building onto the hallway; unmounting is detaching it again.

Your main disks are mounted for you at boot, so the tree is already whole when you log in. To see the seams, two commands. df lists every mounted filesystem with how full it is and where it's mounted. lsblk draws the disks and their partitions as a little tree of hardware. When you plug in a USB stick, a desktop usually mounts it automatically under /media/you/...; on a bare server you mount it by hand: sudo mount /dev/sdb1 /mnt/usb. When you're done, sudo umount /mnt/usb before you pull it out, so any waiting writes actually finish.

What a filesystem actually is

Builds on 8.1.

A raw disk, underneath, is just an enormous row of numbered slots for bytes. It has no idea what a "file" or a "folder" is. A filesystem is the scheme laid over those slots that turns them into named files and folders, each with a size, an owner, permissions, and a date. Linux's usual scheme is called ext4. A stick from a camera is often FAT (you'll see it as vfat) because every device on earth understands it. A drive from a Windows machine is usually NTFS.

The type isn't just trivia... it decides what the disk can remember. ext4 knows about Linux owners and rwx permissions. FAT doesn't, at all. So a file you carefully set to 600 loses that the moment it lands on a FAT stick... not a bug, the stick simply has nowhere to write it down.

Add -T to df and it shows the type of each mounted filesystem. lsblk -f shows the type and the disk's label too. You only pick a type when you format a fresh disk (with a command like mkfs.ext4), which is rare for a beginner... but now the word won't surprise you. The everyday consequence is simple: keep Linux files on an ext4 disk if you care about their owners and permissions, and treat FAT/exFAT sticks as good for plain files you're carrying between machines.

A file with two names: links

Builds on 2.3 (everything is a file) and 8.2.

Here's a quiet truth: the filename isn't the file. The name is a label hanging on the file's real data. Normally a file has exactly one label. But you can add more, in two different ways.

A hard link is a second real label pointing at the exact same data: two names, one file, completely equal. Delete one name and the other still works... the data survives until the last name pointing at it is gone. A symbolic link (symlink) is a different animal: it's a tiny signpost file that just holds the path to another file. Follow it and you land on the target. But delete or move the target and the signpost now points at nothing... a "dangling" link. So: a hard link is a twin name for one thing; a symlink is a shortcut that names a path.

ln original newname makes a hard link... a second true name for the same data. It only works within one filesystem and only for files, not folders. ln -s target linkname makes a symlink, and it's the one you'll reach for: it can cross disks, it can point at a folder, and ls -l shows it plainly as linkname -> target. Symlinks are everywhere on a Linux box once you notice them... for example /usr/bin/python is usually a symlink to python3. Hard links are rarer in daily life; symlinks do most of the real work.

Where did the space go?

Builds on 8.1.

Two questions, two tools. "How full is the disk?" is df... it asks each filesystem for the whole picture: total size, used, free, and the percent. "What in here is using all the space?" is du... it walks a folder and adds up the files inside it. Think of df as the fuel gauge on the dash and du as opening the trunk to see what's so heavy. When a disk fills up (and Linux starts failing to save things), the move is: df to confirm which disk is full, then du to hunt down the hog.

df -h gives every filesystem's used and free space in human sizes. du -sh folder gives one folder's grand total (-s for summary, -h for human). To find a hog, list each subfolder's size and sort it: du -h -d1 . | sort -h... the -d1 means "just one level down," and sort -h puts the biggest last. The classic hunt looks like this: df says / is 98% full, so sudo du -h -d1 / | sort -h, the bottom line is /var, you drill in with sudo du -h -d1 /var | sort -h, and there it is... a folder of old logs.

The app store you type to

Builds on 5.3 (root and sudo).

On a lot of computers, getting a program means finding a website, downloading an installer, and trusting that what you got is really the thing you wanted and nothing else. Linux does it the other way around. There's one command, apt, that acts like an app store for the whole system. You ask it for a program by name, and it goes to a big, curated collection of software called a repository, fetches the package, unpacks it, sets it up, and writes down that it's installed... so later it can remove it just as cleanly. No hunting, no guessing.

It also handles dependencies for you. If the program you asked for needs three other pieces to run, apt notices and brings them along in the same breath. You never assemble a program by hand from parts.

apt is the friendly front you'll type. Underneath it sits an older tool, dpkg, that does the actual unpacking of a Debian package (a .deb file); apt is the part that finds the package, works out the dependencies, and hands the pieces to dpkg. You rarely call dpkg yourself. One line does the whole job: sudo apt install cowsay reads the catalog, sees what cowsay needs, fetches it all, unpacks it, and sets it up. It's sudo because installing software changes the whole machine, not just your files.

The four moves

Builds on 9.1.

Almost everything you'll ever do with packages is four verbs. update refreshes the catalog... it asks the repositories "what's available now, and what versions?" and changes nothing on your machine. upgrade then actually installs the newer versions of what you already have. install adds a new program. remove takes one away. That's the whole day-to-day.

Here's the trap, and nearly everyone falls in it once: update does not upgrade your software. The name feels like it should, but all it does is refresh the list of what's out there. upgrade is the one that changes your machine. So they go together, in that order: refresh the list, then act on it.

The everyday habit is one line: sudo apt update && sudo apt upgrade. The && means "run the second only if the first succeeded", so you refresh the catalog and then upgrade against the fresh list. To add a program it's sudo apt install NAME; to take one away, sudo apt remove NAME, or sudo apt purge NAME if you also want its leftover config files gone. When a program you removed leaves behind dependencies nothing else uses, sudo apt autoremove sweeps them up. And before you install, apt search WORD finds packages by keyword and apt show NAME tells you what one is.

Where it all comes from: repositories and trust

Builds on 9.1.

Why is it safe to install this way when downloading a random program from the web isn't? Because the software comes from repositories your distribution curates, and every package is signed with a cryptographic key. When apt update refreshes the catalog, it checks those signatures... if a package has been tampered with, or comes unsigned from a shelf it doesn't trust, apt refuses it. You're not trusting a stranger's website; you're trusting a known set of shelves whose seal gets checked every time.

The list of shelves your machine trusts lives in a file, /etc/apt/sources.list (and a folder of add-ons, /etc/apt/sources.list.d/). You can add more shelves for software that isn't in the official ones... but each shelf you add is a piece of trust you're extending by hand.

You can read the trusted shelves with cat /etc/apt/sources.list... each line names a repository and what part of it to use. If you download a .deb by hand, the tidy way to install it is sudo apt install ./thing.deb (with the ./, so apt knows it's a file, and it still sorts out dependencies); the older sudo dpkg -i thing.deb installs it but won't fetch anything it depends on. Adding an outside shelf... often called a PPA on Ubuntu... is done with a command like sudo add-apt-repository ppa:some/thing, and from then on its software shows up in apt like any other. Just remember you vouched for it.

apt isn't the only one

Builds on 9.1 and 1.2 (distributions).

Everything so far used apt, because that's what Ubuntu and Debian use. But the idea... ask a trusted place for a program by name, and let it handle the rest... is universal. What changes from one Linux family to another is the command you type and the package format underneath. Back in Module 1 you met distributions; this is where that matters. Fedora and Red Hat use dnf with .rpm packages. Arch uses pacman. Ubuntu uses apt over dpkg and .deb, which you already know. Learn the shape once and "install X on this machine" is never scary, whatever the distro.

There's also a newer way. snap and flatpak are cross-distro formats: a package brings its dependencies bundled inside and runs in a little sandbox, so the same one program works on any distribution. The trade is that these packages are bigger and start a touch slower... the price of carrying their own world with them.

The quickest way to feel it is one task, done three ways. Installing the little system monitor htop is sudo apt install htop on Ubuntu, sudo dnf install htop on Fedora, and sudo pacman -S htop on Arch. Different verbs, identical intent. The cross-distro formats look like snap install htop or flatpak install htop, and they'll run the same on any of those systems. You don't need to memorize all of them... you need to know that the manager is the first thing you find out about a new distro, and the idea carries over intact.

Finding lines with grep

Builds on 4.2 (pipes) and 3.4 (wildcards).

You met grep in passing back with pipes. Here it earns a lesson of its own, because it's the tool you'll reach for most. Think of it as a sieve for lines: you give it a pattern, it reads text a line at a time, and it keeps only the lines that match, letting the rest fall away. Point it at a file, or feed it the output of another command through a pipe, and suddenly a thousand-line log becomes the five lines you cared about.

The pattern can be a plain word, but grep also speaks regular expressions... a tiny language for describing shapes of text. Four pieces get you a long way: ^ means "start of the line", $ means "end of the line", . means "any one character", and * means "the thing before me, repeated". So ^WIN finds lines that begin with WIN, and failed$ finds lines that end with failed.

The shape is grep PATTERN file, or something | grep PATTERN to sieve another command's output. The flags you'll lean on: -i ignores case (win matches WIN), -v inverts it (keep the lines that don't match), -n prefixes each hit with its line number, and -c just counts the matches instead of printing them. Wrap a pattern in single quotes when it has special characters, so the shell hands it to grep untouched.

Columns and counting

Builds on 10.1 and 4.2 (pipes).

A lot of text is really a table: rows of records, each split into fields by a comma or a space or a colon. cut pulls out the fields you want. You tell it the delimiter with -d and which field with -f, and it hands back just that column. Then comes the pipeline everyone learns and never forgets: sort | uniq -c. uniq collapses adjacent duplicate lines, and -c counts them... but it only sees duplicates that sit next to each other, so you sort first to line them up. Together they answer "how many of each?" for anything.

cut -d, -f2 file means "split each line on commas, give me field 2". You can ask for several: -f1,3, or a range -f2-4. The counting pipeline is sort | uniq -c, and the reason sort has to come first is that uniq only notices duplicates that are next to each other. A common companion is tr, which swaps characters wholesale... tr 'a-z' 'A-Z' uppercases everything it's fed, and tr -d deletes characters. And when a file has a header row you don't want, tail -n +2 starts from line 2.

Find and replace with sed

Builds on 10.1 (patterns).

sed is a stream editor. Instead of opening a file, scrolling, and typing, you tell sed a rule and it applies that rule to every line as the text flows past. The rule you'll use ninety percent of the time is substitute: s/old/new/ replaces the first old on each line with new. Add a g on the end... s/old/new/g... and it replaces every match on the line, not just the first. That's the whole core of it.

Because it works on a stream, sed is happiest in a pipe or pointed at a file, printing the edited result to the screen. It doesn't change the file itself unless you explicitly ask it to... so you can experiment freely and just watch the output.

The substitute rule is sed 's/OLD/NEW/', and the slashes just separate the three parts: find OLD, put NEW. Without g it changes the first match on each line; with g it changes them all. You can also select lines: sed -n '2,4p' prints only lines 2 through 4 (the -n says "don't print everything, only what I mark with p"), and sed '1d' deletes the first line... a tidy way to drop a header. It reads from a file or a pipe, and by default just prints the result, leaving the original alone.

A tiny program per line, with awk

Builds on 10.2 (columns).

Where cut grabs a column and sed rewrites text, awk does the thing they can't: it treats each line as a row of fields and runs a tiny program on every one. It splits the line for you and hands you the pieces as $1, $2, $3, and so on, with $NF meaning "the last field" and $0 the whole line. You write a rule in the shape pattern { action }: for each line, if the pattern is true, do the action. Leave the pattern off and it runs on every line; leave the action off and it just prints matching lines.

Two jobs cover most of what a beginner needs. First, printing chosen fields: awk '{print $1}' prints the first field of every line. Second, adding a column up: you keep a running total across the lines and print it at the very end, in a special END block that runs once after the last line.

Tell awk the delimiter with -F (for a CSV, -F,), then give it a program in single quotes. awk -F, '{print $2}' pets.csv prints the second field of every line, just like cut. Patterns make it choosier: awk -F, '$2=="mammal" {print $1}' prints the name only on the rows whose kind is mammal, and NR>1 means "skip line 1" (NR is the current line number). The classic total: awk -F, 'NR>1 {sum+=$3} END {print sum}' adds field 3 down the whole file and prints it once at the end. Two commas of syntax, and you can answer questions no single-purpose tool can.

Every machine has an address

Builds on 1.1 (what a computer is).

For two machines to talk, each needs an address, the same way a letter needs one. On a network that address is an IP address, a set of numbers like 192.168.1.42. Your home router hands one out to every device that joins... your laptop, your phone, the printer... so they can find each other. A machine reaches the network through an interface (your wifi or an ethernet cable), and it can have several: one for the real network, and a special built-in one called loopback that always points back at itself.

That loopback interface has the address 127.0.0.1, and the name localhost. When a program says "connect to localhost", it means "connect to this very machine"... the message never leaves the box. It's how a web server and a browser on the same computer talk during testing.

To see your own addresses, ip addr lists every interface and the address on it. You'll always see lo (loopback, 127.0.0.1) and usually one real interface like eth0 (a cable) or wlan0 (wifi) carrying the address your router gave you. For just the useful number, hostname -I prints your machine's address on the network. Addresses that start with 192.168. or 10. are private... they only mean something inside your own network, which is why every home tends to reuse 192.168.1.x.

Names and reachability

Builds on 11.1.

Machines find each other by number, but people can't remember numbers, so we use names. example.com is a name; behind it sits an address like 93.184.216.34. The system that turns names into addresses is DNS, the phone book of the internet. Every time you open a site, your machine quietly asks DNS "what's the number for this name?" and then connects to the number.

Once you have an address, the simplest question is "is anything there, and is it answering?" That's ping. It sends a tiny "are you there?" packet and waits for the echo back, reporting how long the round trip took. Fast replies mean a healthy path; no replies mean the machine is off, unreachable, or ignoring you. Splitting those two questions... does the name resolve, and does the address answer... is how you find where a problem lives.

host NAME (or dig NAME +short) does just the lookup and shows you the address a name points to. ping NAME resolves the name and then sends those little echo requests; add -c 3 to send just three and stop, instead of pinging forever. If host gives you an address but ping gets no reply, the name is fine and the machine is the problem. If host itself fails, the name never resolved... a DNS problem, before reachability even enters the picture.

Ports and talking to servers

Builds on 11.2 and 6.1 (processes).

An address gets you to the right machine, but a machine runs many services at once... a web server, a mail server, a remote-login service. So each service waits behind a numbered door called a port. Web pages come through port 80 (or 443 for the secure version), remote login through port 22. When you connect, you're really connecting to an address and a port: "machine 93.184.216.34, door 443".

The one that knocks is the client; the one waiting behind the door is the server. Your browser is a client; the web server is a server. And a server is just a program (a process, from Module 6) that has claimed a port and is listening on it. curl lets you be the client from the command line: hand it a URL and it knocks on the right door, sends the request, and prints whatever comes back.

curl URL fetches whatever's at that address and prints it... for a web page, that's the raw HTML. Add -I and it asks for just the headers: the server's short status reply, like HTTP/1.1 200 OK, where 200 means "here you go" and 404 means "no such page". You rarely type the port... http:// assumes 80 and https:// assumes 443... but you can spell it out with a colon, as in example.com:80. Its cousin wget does the same fetch but saves the result to a file instead of printing it, which is handy for downloads.

Who's listening, and reaching other machines

Builds on 11.3 and 6.4 (services are processes).

You've been the client, knocking on other machines' doors. Now turn it around: which doors are open on your machine? A service that's listening has claimed a port and is waiting for knocks, and ss shows you exactly which ones. That's worth knowing... an open port is a way in, so you want to be able to answer "what's listening here, and did I mean for it to be?"

The most useful door of all is 22, where ssh waits. ssh ("secure shell") opens a shell on another machine over an encrypted connection, so you can work on a computer across the room or across the world as if you were sitting at it. It's how nearly all remote Linux work happens. And a firewall is simply a guard at the doors: a set of rules about which ports may be knocked on from where, so you can leave a service running but only let the right people reach it.

ss -tln is the everyday incantation: -t for TCP, -l for listening, -n for plain numbers instead of names. It prints a row per open door, with the local address and port. To reach another machine, ssh user@address... for example ssh sam@192.168.1.50... and after it checks the machine's identity and your login, your prompt is now a shell on that machine; type exit to come home. On Ubuntu the firewall is usually ufw, and a rule reads as plainly as ufw allow 22 ("let people reach the ssh door").

nano, the friendly editor

Builds on 3.2 (making and editing files).

Editing a file in a graphical program is obvious: you see the text, you click, you type, you save. In the terminal there's no window... the editor takes over the whole screen instead. nano is the editor that makes this painless. You open a file, you just type (no modes, no tricks), and the two rows along the bottom remind you of every shortcut. It's the editor you can be productive in immediately, which is exactly why it's the one to reach for when you're not sure.

Those shortcuts use the Ctrl key, and nano writes it as ^. So ^O on the bar means "hold Ctrl and press O", and it means Write Out... save. ^X is Exit. Save with ^O (it asks you to confirm the filename... just press Enter), then leave with ^X. That's the whole editor.

Open a file with nano notes.txt (it's created if it doesn't exist). Type normally, use the arrow keys to move, Backspace to delete. When you're done, press Ctrl+O to save... nano shows the filename at the bottom and you press Enter to confirm... then Ctrl+X to leave. If you try to exit with unsaved changes, nano won't just lose them: it asks "Save modified buffer?" and you answer Y or N.

You can actually do this right now. Open the practice terminal (the button at the bottom-right of this page) and type nano notes.txt. The editor takes over the panel, shortcut bar and all. Add a line, press Ctrl+O then Enter to save, and Ctrl+X to come back to the shell. Then cat notes.txt to see your change stuck.

vim and the two modes

Builds on 12.1.

People get stuck in vim for one reason: they expect to just type, and instead the letters seem to do weird things. That's because vim has modes. When it opens, you're in Normal mode, where the keys are commands, not text... x deletes a character, dd deletes a line. To actually type, you switch to Insert mode by pressing i. Now the keys are text, just like any editor. When you're done typing, press Esc to go back to Normal mode. That's the whole secret: i to type, Esc to command.

Saving and quitting happen from Normal mode. Press : and a little command line appears at the bottom; there you type w to write (save), q to quit, or wq to do both, then Enter. And the famous escape hatch, the one everyone eventually searches for: :q! means "quit and throw away my changes" ... the way out when you've made a mess and just want to leave. Press Esc first (to be sure you're in Normal mode), then :q! and Enter.

Open a file with vim notes.txt. You land in Normal mode... don't panic, don't type yet. Press i and you'll see -- INSERT -- at the bottom; now type like normal. Press Esc to return to Normal. To save and quit: Esc, then :wq, then Enter. To quit without saving: Esc, then :q!, then Enter. If you try a plain :q with unsaved changes, vim stops you with E37: No write since last change... that's your cue to either :w first or :q! to abandon.

Try the whole loop safely in the practice terminal: type vim notes.txt, press i, type a line, press Esc, then type :wq and Enter. You just edited and saved a file in vim... and you know the way out. Do it a few times and the fear is gone for good.

Getting things done in vim

Builds on 12.2.

Surviving vim is knowing the modes. Using vim is a small vocabulary of Normal-mode commands that, once in your fingers, are genuinely fast, because your hands never leave the keyboard. You don't need many. Move with h j k l (left, down, up, right... arrows work too while you learn), jump to the top of the file with gg and the bottom with G. Edit with x (delete the character under the cursor), dd (delete the whole line), and the one everyone loves, u (undo). Those handful of keys cover most of a day.

Two more earn their keep. /word then Enter searches forward for "word" and drops your cursor on it. And the power move: :%s/old/new/g replaces every "old" with "new" in the whole file... the same substitute idea you met in sed, now inside the editor. The % means "all lines", the g means "every match on each line".

All of these are Normal-mode commands, so press Esc first if you've been typing. To delete three lines, dd three times. Made a mistake? u undoes it, one step per press. To fix a typo everywhere, :%s/teh/the/g and Enter corrects every "teh" in the file at once. Searching with / is how you get somewhere fast in a long file... type /error, Enter, and you're on the first "error". None of this is memory work at first; keep the card above beside you and it sinks in within a week.

In the practice terminal, open a file with vim pets.csv, press Esc to be sure you're in Normal mode, and try it: dd to delete a line, u to bring it back, then :%s/mammal/MAMMAL/g and Enter to replace every "mammal". Save and quit with :wq, then cat pets.csv to see the result.

Choosing, and the editor that opens itself

Builds on 12.1 and 12.2.

Which editor? For a quick change... a config line, a note... nano is faster to get in and out of, especially while you're still learning. For real editing you do a lot of, vim pays back the learning curve in speed. There's no wrong answer; many people use nano for two-minute jobs and vim for everything else. What matters is that you can save and quit both, because sometimes the computer picks the editor for you.

That's the part nobody warns you about. Certain commands open an editor themselves: writing a commit message with git commit, scheduling a job with crontab -e, editing the admin file with sudo visudo. If the system's default editor is vim and you weren't ready for it, that's exactly the moment people panic. Now you won't: it's just vim (or nano), and you already know :wq or Ctrl+X. You can even choose which one opens by setting the EDITOR variable... export EDITOR=nano makes all of these use nano.

export EDITOR=nano (or =vim) sets your preferred editor for the current session; put that line in a shell startup file like ~/.bashrc (which you'll meet in Course 301) to make it stick. When git commit or crontab -e opens, it opens that editor. Beyond these two, you'll hear about emacs, vim's famous rival... just as deep, a different philosophy... and about graphical editors like VS Code that many people use for big projects. You don't have to choose a side. Knowing your way around nano and vim means no terminal, anywhere, can ever trap you in a file.

In the practice terminal, try both and feel the difference: nano notes.txt (type, Ctrl+O, Ctrl+X) then vim notes.txt (i, type, Esc, :wq). Same file, two very different feels... now both are yours.

A script is just saved commands

Builds on 12.1 (editing files) and 5.2 (permissions).

Here's the quiet magic at the end of the course: a script is nothing more than the commands you already know, saved in a file so the shell can run them all in order. Write three echo lines in a file, and running that file prints all three. No new language to learn... the shell is the language, and you already speak it.

Two small conventions make a file a proper script. The first line is usually #!/bin/bash, the shebang, which tells the system "run this with bash". And any line starting with # is a comment... a note for humans that the shell ignores. To run a script you either hand it to bash directly (bash script.sh), or you mark the file executable with chmod +x (permissions, from Module 5) and run it as ./script.sh.

Write the file with an editor you now know... nano hello.sh. Put #!/bin/bash on the first line, then your commands. Save and exit. Now bash hello.sh runs it. If you'd rather run it as its own little program, chmod +x hello.sh turns on the execute permission and then ./hello.sh works (the ./ means "the one right here in this folder"). Comments starting with # are ignored by bash, so use them freely to explain what a script does.

In the practice terminal, write your own: nano first.sh, type #!/bin/bash on line one and echo "I made a script!" on line two, save with Ctrl+O and exit with Ctrl+X. Then bash first.sh. You just wrote and ran a program.

Variables and input

Builds on 13.1.

A variable is a named box that holds a value. You put something in with name=value (no spaces around the =), and you get it back out by putting a $ in front: $name. So name="Sam" then echo "Hi, $name!" prints Hi, Sam!. One catch you already met in Module 12's cousin: double quotes let $name expand, but single quotes are literal, so 'Hi, $name' prints the dollar sign and all.

Two more ways to fill a variable make scripts genuinely useful. $(...) runs a command and hands you its output... today=$(date) puts the date into today. And a script can take arguments: when you run ./greet.sh Sam, the script sees Sam as $1 (the first argument), $2 would be the second, and so on. For a value typed while the script runs, read name waits for the person to type a line and stores it in name.

Assignment is strict about spaces: name="Sam" works, name = "Sam" does not (the shell would think name is a command). Wrap values with spaces in quotes. Use "$name" in double quotes almost always, so the value comes through cleanly. Inside a script, $1, $2, $3 are the arguments in order, and $# is how many there were. And read answer pauses for the person to type, then continues with their text in answer... the start of an interactive script.

In the practice terminal, meet read: type read color and press Enter, then type a colour and Enter, then echo "You picked $color". The shell remembered what you typed. That's how a script asks a question.

Making decisions

Builds on 13.2.

A program gets interesting when it can choose. In bash that's if: "if this is true, do that; otherwise do the other thing." The shape reads almost like English: if a condition, then some commands, maybe else some others, and fi to close it (that's if backwards... bash's little joke). The condition is usually a test written in square brackets: [ $x -gt 5 ] asks "is x greater than 5?". Mind the spaces inside the brackets... they're required.

Underneath, every command reports whether it succeeded with an exit code: 0 means success, anything else means failure, and the last one is stored in $?. That's what if really checks. It's also what lets you chain commands: A && B runs B only if A succeeded, and A || B runs B only if A failed. So mkdir data && cd data means "make the folder, and only if that worked, go into it".

The full shape is if [ CONDITION ]; then COMMANDS; else COMMANDS; fi, and you can spread it across lines or keep it on one with semicolons. Number tests use -gt (greater), -lt (less), -eq (equal), -ge, -le, -ne; text uses = and != (as in [ "$name" = "Sam" ]); and file tests like [ -f notes.txt ] ask "does this file exist?". Check $? right after a command to see if it worked, and reach for &&/|| when a whole if would be more than the moment needs.

Doing it many times

Builds on 13.3 and 10.2 (columns).

The last piece is repetition. A for loop walks through a list and runs its body once for each item: for i in a b c; do echo $i; done prints a, then b, then c. The list can be words you type, numbers from $(seq 1 5), or files from a wildcard like *.txt. A while loop is the other flavour: it keeps running as long as a condition stays true, which is how you count, or wait for something. Both open with do and close with done.

And that's the whole toolkit. Commands, variables, decisions, loops. Put them together and you can write a script that does a real job... reads some data, decides what matters, and reports it. The little pets report below loops over each kind of animal, counts how many there are with tools from Module 10, and prints a tidy summary. Thirteen modules ago you were looking at a blinking cursor; now you're writing programs.

A for loop is for VAR in LIST; do COMMANDS; done, and each time around, VAR holds the next item. A while loop is while [ CONDITION ]; do COMMANDS; done, and you make sure something inside changes, or it never stops (n=$((n+1)) does simple arithmetic to move a counter along). The capstone script below pulls it all together: a for over the animal kinds, a $(...) capture that counts each with grep -c, and an echo to report... a genuine little program built entirely from pieces you now know.

In the practice terminal, write the capstone in your own words: nano mine.sh, and inside, loop over a few things and echo each with a variable. Save, then bash mine.sh. Change the list, run it again. That loop of write, run, tweak is programming... and you're doing it, right here in the page.

The environment

Builds on 13.2 (variables).

Every shell carries a set of variables that describe your world, called the environment. You've already used some without knowing: $HOME is your home folder, $USER is your name, $HOSTNAME is the machine's. These aren't magic... they're just variables that were set for you when you logged in, and programs read them to know where "home" is or who you are.

Here's the distinction that matters. A variable you set with name=value lives only in this shell. If you export it, it becomes part of the environment, and every program you launch from this shell inherits it too. That's why settings like your preferred editor are exported... so the programs you run can see them. env shows you everything currently in the environment.

Read any environment variable the usual way, with a $: echo $HOME. See the whole environment with env (it's long... pipe it through grep to find one, as in env | grep PATH). To add something, export NAME=value: for example export EDITOR=nano tells every program that opens an editor to use nano. A plain NAME=value without export still works, but only in the current shell... fine for a quick variable in a script, not for a setting programs need to see.

Aliases: your own shortcuts

Builds on 14.1.

If you type ls -l forty times a day, why type all four characters? An alias is a nickname you invent for a command: alias ll='ls -l' means "whenever I type ll, run ls -l." From then on ll just works. Aliases are the gentlest, most satisfying bit of customization... small, immediate, and entirely yours. Most people collect a handful they can't live without.

The shape is alias name='the full command', with the command in single quotes so it's taken literally. Type alias by itself to see the ones you have, and unalias name to drop one. Like everything you set at the prompt, an alias lasts only for this session... but in the next lesson you'll learn where to put them so they're there every time.

alias ll='ls -l' creates it; now typing ll (with any extra arguments, like ll notes.txt) runs ls -l with them. alias on its own lists everything you've defined, and unalias ll removes one. You can alias anything: a long command you always mistype, a chain you run often, or a friendlier name. The single quotes keep the command literal so nothing expands too early.

In the practice terminal, make your own: alias hi='echo hello there', then type hi. Invent one for a command you find yourself typing a lot. When you're done playing, unalias hi takes it away.

.bashrc, the startup file

Builds on 14.1, 14.2, and 12.1 (editing).

Everything you've set at the prompt so far... exports, aliases... disappears when you close the terminal. The fix is a file called ~/.bashrc in your home folder (the leading dot makes it hidden, which is why you haven't seen it). Bash reads this file every time a new shell starts and runs the lines in it. So anything you'd type to set up your shell, you write there once, and it's done for you forever after. Your export EDITOR=nano, your favourite aliases... they live in ~/.bashrc.

There's one catch people trip on: editing ~/.bashrc doesn't change your current shell, because bash only read it at startup. Either open a new terminal, or... better... run source ~/.bashrc, which re-reads the file into the shell you're in right now. "Source" means "run this file's lines here, as if I'd typed them", so your changes take effect immediately.

Open it with the editor you know: nano ~/.bashrc. You'll usually find some lines already there. Add your own... an export, some alias lines... save and exit. Then source ~/.bashrc (or the shorthand . ~/.bashrc) re-reads it so your current shell picks up the changes. Every new terminal from now on runs it automatically. This one file is where "my shell, set up my way" actually lives.

In the practice terminal: nano ~/.bashrc, add a line like alias week='echo it is a good week', save (Ctrl+O, Enter) and exit (Ctrl+X). Type week... nothing yet, because this shell hasn't re-read the file. Now source ~/.bashrc, and week works. That's the whole loop.

PATH and your own commands

Builds on 14.1, 14.3, and 13.1 (scripts).

When you type ls, how does the shell know where ls actually lives? It looks in $PATH: a list of folders, separated by colons, that it searches in order until it finds a program with that name. ls is in /usr/bin, which is on the PATH, so it just works from anywhere. A script sitting in your current folder isn't on the PATH, which is exactly why you have to spell it out as ./myscript.sh... the ./ says "not on the PATH, right here."

So here's the mastery move: make a folder for your own commands, put it on the PATH, and drop your scripts in it. The custom is a bin folder in your home: ~/bin. Add it to the PATH (once, in ~/.bashrc, with export PATH="$HOME/bin:$PATH"), make a script executable there, and you can run it by name from anywhere, exactly like a built-in command. Your own tools, first-class citizens.

See your PATH with echo $PATH... a colon-separated list. The ~/.bashrc you looked at already adds your personal folder with export PATH="$HOME/bin:$PATH" (note it keeps the old $PATH on the end, so nothing is lost). Now the recipe: write a script, move it into ~/bin, make it executable with chmod +x, and type its name. The shell finds it on the PATH and runs it, no ./ needed. You've turned a script into a command... the same way every tool on the system got there.

In the practice terminal, make your own command from scratch: nano ~/bin/wave, write #!/bin/bash then echo "o/", save and exit. Then chmod +x ~/bin/wave, and type wave from anywhere. You just added a command to your system... the same move that put every other tool there.

What a service is

Builds on 6.1 (processes) and 6.4 (services are processes).

Most commands you've run start, do their thing, and finish, right there in front of you. A service is different: it's a program meant to run in the background, continuously, without anyone watching. The SSH server that lets you log in remotely, the scheduler that runs jobs at set times, a web server... these all just sit there, running, ready. The old Unix word for one is a daemon.

Something has to start all these at boot, keep them running, and restart them if they crash. On modern Linux that's systemd, and it's special: it's process 1, the very first thing the kernel starts, the ancestor of everything else (you saw PID 1 back in Module 6). You talk to it with one command, systemctl, and systemctl status NAME shows you everything about a service at a glance: whether it's loaded, whether it's running, its main process, and its most recent log lines.

You inspect a service with systemctl status NAME. The first line's dot tells you at a glance: a filled ● means running, a hollow ○ means stopped. Then Loaded says systemd knows about it (and whether it's set to start at boot), Active says whether it's running right now and since when, Main PID is its process, and the last few log lines show what it's been up to. Reading a service is almost always the first thing you do... before you touch anything, you look.

Controlling services

Builds on 15.1 and 5.3 (sudo).

Once you can read a service, controlling it is four verbs. systemctl start NAME gets it running, stop halts it, and restart stops then starts it again (the classic fix for "it's gone weird... turn it off and on"). status, which you already know, is how you check. Because services affect the whole machine, not just your files, changing one needs sudo... but just looking (status, is-active) does not.

A small nicety: systemctl is quiet on success. Run sudo systemctl start nginx and, if it worked, you get... nothing. No news is good news. To confirm, ask: systemctl is-active nginx answers active or inactive in one word, perfect for a quick check or a script.

To bring a stopped service up: sudo systemctl start nginx. To take it down: sudo systemctl stop nginx. When a service is misbehaving, sudo systemctl restart nginx is the reliable reset. After any change, systemctl status nginx shows the full picture, or systemctl is-active nginx gives the one-word answer. Forget the sudo and systemd will refuse with an "access denied", because you're asking to change something that belongs to the whole system.

In the practice terminal: systemctl status nginx (stopped), then sudo systemctl start nginx, then systemctl status nginx again... watch the dot fill in and Active flip to running. sudo systemctl stop nginx puts it back. Try start without sudo and read the refusal.

Start now, or start at boot?

Builds on 15.2.

Here's the distinction that trips up nearly everyone, and it's worth pausing on. start runs a service right now, this once. enable is a completely separate thing: it tells systemd "run this automatically every time the machine boots." They don't imply each other. You can start a service without enabling it (it's running now, but won't come back after a reboot). You can enable one without starting it (it'll come up next boot, but isn't running yet). Most real setups want both: start it now, and enable it so it survives a reboot.

This is the same shape as the update-versus-upgrade trap from Module 9: two words that sound related but do different jobs. Keep them straight and services stop being mysterious. Two one-word questions keep you honest: systemctl is-active NAME ("running right now?") and systemctl is-enabled NAME ("set to start at boot?").

sudo systemctl enable nginx sets it to start at boot (it prints a line about creating a symlink... that's systemd wiring it into the boot sequence). sudo systemctl disable nginx undoes that. Neither one touches whether it's running right now... for that you still start or stop. When you want a service properly set up, do both: sudo systemctl enable --now nginx is even a shortcut that enables and starts in one go. Check your work with the two questions: is-active and is-enabled.

What's it doing? Reading a service's logs

Builds on 15.1.

A background service can't pop up a window to tell you what happened, so instead it writes a running diary... log lines... as it works. systemd gathers every service's diary into one place called the journal, and you read it with journalctl. This is how you answer the question you'll ask constantly once you run services: "why did that just do that?" The answer is almost always in the logs.

You've actually already seen a preview: the bottom of systemctl status shows a service's most recent lines. For more than a peek, journalctl -u NAME shows that one service's whole diary. Each line carries a timestamp, the machine's name, and which program wrote it... so you can see exactly what happened and when. (Logs are a big enough topic to get their own module soon; this is your first, most useful slice.)

Start with systemctl status NAME... the last few log lines at the bottom are often all you need. When you want the fuller story, journalctl -u NAME shows that service's log. It can be long, so the same habits help: pipe it through grep to find a word, or use journalctl -u NAME -n 20 for just the last 20 lines. And journalctl -u NAME -f follows the log live, printing new lines as they arrive... the way you watch a service while you poke at it. There's a whole module on logs coming; for now, "status first, then journalctl -u" will answer most questions.

Why schedule, and meet cron

Builds on 15.1 (services) and 13.1 (scripts).

You already know how to write a script that does a job. The next step up is having it run on its own, at set times, forever, without you. That's the difference between doing a task and operating a system. Backups at 2am, a log cleanup every Sunday, a "good morning" summary at 7... none of these should need a human to remember them.

The tool for recurring jobs is cron, and it's exactly the kind of background service you met last module. It wakes up once a minute, every minute, looks at everyone's schedules, and runs whatever is due right then. Your schedule is a little table called a crontab ("cron table"): each line says when to run something and what to run. Cron reads it and does the rest.

You don't start or stop cron yourself... it's a service that's simply always running (you could systemctl status cron and see it, from last module). What you manage is your crontab, your own list of scheduled jobs. Every user has one. You look at it, you edit it, and cron takes it from there. The next lessons are all about reading and writing those schedule lines... which is really the whole skill.

Your crontab

Builds on 16.1 and 12.1 (editing).

Two commands manage your whole schedule. crontab -l lists what you've got. crontab -e edits it... and here's a lovely payoff from Course 301's first module: it opens your crontab in whatever editor $EDITOR points to. You set export EDITOR=nano, so crontab -e opens nano. Add or change lines, save, exit... and cron picks up the new schedule automatically. No restart, no fuss.

Each line has the same shape: five time fields, then the command to run. The five fields, in order, are minute, hour, day-of-month, month, and day-of-week. So 0 7 * * * echo "good morning" reads as "at minute 0 of hour 7, every day, run the echo." A * means "every" for that field. Get comfortable with that shape and cron is basically solved... the next lesson zooms into the fields.

crontab -l prints your current schedule (lines starting with # are comments, ignored by cron... great for labelling what a job does). crontab -e opens it for editing; the first time, you may get an empty file with a helpful header. Write your lines, save, exit. To wipe your whole crontab, crontab -r (careful... that's all of it, gone). You almost never edit the crontab file directly on disk; you always go through crontab -e, which validates it and tells cron to reload.

In the practice terminal: crontab -e opens your schedule in nano (the editor from Module 12, the setting from Module 14... it all connects). Add a line like 30 8 * * 1 echo "Monday standup", save with Ctrl+O and exit with Ctrl+X, then crontab -l to see it stuck.

Reading the five fields

Builds on 16.2.

The whole art of cron is those five fields, so let's pin them down. In order they are: minute (0–59), hour (0–23, so 24-hour time), day of month (1–31), month (1–12), and day of week (0–6, where 0 is Sunday). A * in a field means "every". So 0 2 * * * is "minute 0, hour 2, every day of the month, every month, every day of the week" ... that is, 2:00 every morning.

Four symbols cover almost everything. * is "every". */n is "every n" ... */15 in the minute field means every 15 minutes. A range with a dash, 1-5 in the weekday field, means Monday through Friday. A list with commas, 0,30 in the minute field, means "at 0 and 30". Combine them and you can say almost any schedule in five little fields.

Read left to right, field by field, and translate. A few you'll reach for constantly: 0 2 * * * is every day at 2am; */15 * * * * is every 15 minutes; 0 9 * * 1-5 is 9am on weekdays; 0 0 1 * * is midnight on the first of every month. There are also friendly shortcuts that replace all five fields: @daily (midnight every day), @hourly, @weekly, @reboot (once, when the machine starts up). When in doubt, write the schedule in words first, then translate it field by field.

Just once, and the modern way

Builds on 16.1 and 15.1 (services).

cron is for things that repeat. Sometimes you want the opposite: run a command once, later, then forget it. That's at. You give it a time and a command, and it fires that one time... "compile this at midnight when nobody's using the machine," and you can log off. It even has a little queue you can inspect (atq) and clear (atrm).

There's also a newer way to do recurring jobs: systemd timers. Since systemd already manages your services (Module 15), it can also start them on a schedule, with a companion timer unit. Timers are more powerful than cron... they log to the journal, can catch up on missed runs, and depend on other units... which is why modern system packages increasingly ship timers instead of cron jobs. You can see the ones on a machine with systemctl list-timers. For your own quick jobs, cron is still perfectly good and simpler; timers are what you'll meet in the plumbing of a modern system.

For a one-off, pipe a command into at with a time: echo "backup.sh" | at 22:00 queues it for 10pm tonight. atq shows the queue, atrm N cancels job N. For the modern recurring approach, you don't usually write timers by hand as a beginner, but you'll see them: systemctl list-timers shows what's scheduled and when it next fires. The rule of thumb: reach for at when it's once, cron when it's your own simple repeat, and know that timers are what modern packages use under the hood.

The user database

Builds on 5.1 (users) and 7.2 (groups).

To the system, a "user" isn't really a name... it's a number, the UID, and a line in a plain text file called /etc/passwd. Each line holds seven colon-separated fields: the name, an x placeholder for the password, the UID, the primary group's GID, a description, the home folder, and the login shell. root is always UID 0... that's what actually makes root special, the zero, not the name.

Most of the entries aren't people at all. UIDs 1 to 999 are system users... accounts that services run as, so a web server isn't running as you or as root. Real humans start at 1000 (that's you: sam is 1000). And the passwords? They're deliberately not in /etc/passwd (which everyone can read). They live in /etc/shadow, readable only by root, so even though anyone can list the users, nobody but root can get at the password hashes. The x in the passwd line is just a pointer saying "the real secret is over in shadow."

Read the users with cat /etc/passwd... it's just text, and everyone can look. Groups are the same idea in /etc/group. But try cat /etc/shadow as yourself and you'll get "Permission denied"... that file is locked to root on purpose, because it holds the (hashed) passwords. With sudo you can read it. A cleaner way to query either database is getent: getent passwd sam pulls just that user's line, and getent group sudo shows who's in a group.

Creating and managing users

Builds on 17.1.

Adding a user is one command, and because it changes the whole system it needs sudo. sudo useradd -m -s /bin/bash jo creates jo: the -m makes their home folder, and -s sets their login shell. That one command writes the /etc/passwd line, creates a matching group, adds a /etc/shadow entry, and builds /home/jo. New users have no password yet (they can't log in until they get one), so you follow up with sudo passwd jo.

Two more verbs round it out. usermod changes an existing user... their shell, their groups, their name. userdel removes one, and userdel -r also deletes their home folder and mail. On many systems there's also adduser, a friendlier, interactive wrapper around useradd that asks you the questions and sets sensible defaults... handy, but useradd is the one that's everywhere.

The everyday create is sudo useradd -m -s /bin/bash NAME, then sudo passwd NAME to set a password. Check your work with getent passwd NAME or id NAME (which shows their UID and groups). To change a user later, usermod: sudo usermod -s /bin/bash NAME changes their shell, and its group options are the next lesson. To remove someone, sudo userdel NAME, or sudo userdel -r NAME to take their home folder with them. All of it needs sudo, because you're editing accounts the whole machine shares.

In the practice terminal: sudo useradd -m -s /bin/bash robin, then getent passwd robin and id robin to see the new account. Give it a password with sudo passwd robin. When you're done, sudo userdel -r robin removes it cleanly.

Groups and membership

Builds on 17.2 and 7.2 (groups share access).

Back in Course 101 you saw that groups let people share access. As an admin, you're the one who puts people in them. Every user has one primary group (usually a group of their own, matching their name) and any number of secondary groups that grant extra access... being in the sudo group, or a family group that owns a shared folder. groups NAME and id NAME show which groups someone is in.

You add someone to a group with usermod, and here is the single most important detail in this whole module: use -aG, not just -G. The -G flag sets a user's secondary groups... it replaces the whole list. The -a means "append". So usermod -aG sudo jo adds jo to sudo and keeps their other groups; usermod -G sudo jo would make sudo their only secondary group and silently drop the rest. Countless people have accidentally removed themselves from groups by forgetting the -a. Always -aG.

Make a group with sudo groupadd NAME. Add a user to one (or several) with sudo usermod -aG group1,group2 NAME. Check with groups NAME or getent group NAME (which lists the members). A group change takes effect on the user's next login... a logged-in session keeps its old groups until it starts fresh, which surprises people who add themselves to a group and wonder why it "didn't work" yet. And the golden rule bears repeating: to add a group without disturbing the others, it's -aG every time.

The keys to sudo

Builds on 17.3 and 5.3 (root and sudo).

You've typed sudo since Course 101. Now the reveal of why it works for you: you're in a special group (called sudo on Ubuntu, wheel on some systems), and there's a rule that says "members of that group may run commands as root." Grant someone sudo power and you're really just doing what you learned last lesson: sudo usermod -aG sudo NAME. Take it away by removing them from the group. The group is the keyring.

The rules themselves live in /etc/sudoers, and there's one iron law: never edit it with a normal editor... always use visudo. Why? visudo checks your changes for mistakes before saving. A single typo in /etc/sudoers can break sudo for everyone, including you, leaving no way to fix it (you'd need sudo to repair the file that broke sudo). visudo is the seatbelt. And the guiding principle behind all of this is least privilege: give each person and service the least access that lets them do their job, and no more. Not everyone needs sudo; most things shouldn't run as root.

To make someone a sudoer, add them to the group: sudo usermod -aG sudo NAME. To see the rules, sudo cat /etc/sudoers... you'll find %sudo ALL=(ALL:ALL) ALL, where the % means "the group named sudo" and the line reads "may run any command, as anyone." To change the rules, sudo visudo opens the file in your editor but validates it on save, refusing to write a broken file. For extra rules, drop small files in /etc/sudoers.d/ rather than editing the main file. Through all of it, lean toward least privilege... the fewer people and processes with root, the fewer ways things go wrong.

In the practice terminal: groups to see that you're in sudo, then sudo cat /etc/sudoers to read the rule that grants it. Try sudo visudo to open the file in the editor (it's how you'd add a rule for real). Make a user with sudo useradd -m robin and grant them power: sudo usermod -aG sudo robin, then groups robin.