The shell — study guide
The concept's fragments, read in order.
A text prompt that runs commands
The shell is a program that waits for you to type a line, runs it, and waits again. That is the whole loop: it prints a prompt, you type one command line, it does what the line says, and then the prompt comes back for the next one. Nothing happens until you press enter, and everything you can do to the machine you do one typed line at a time.
That makes working in the shell like a back-and-forth text exchange where you send one line, it acts and replies, and it waits for your next line — you say one thing, it acts and answers, and it holds still until you say the next. A command line is just text, so it is exact, repeatable, and easy to write down; the same line typed tomorrow does the same thing it did today.
Every command line names a program to run and, usually, some extra words that tell that program what to work on and how. The rest of this concept is the shape of that line, the handful of commands for moving around a filesystem and reading what is there, and the two ways — redirection and pipes — of routing a command's output somewhere other than the screen.
Command, arguments, options
A command line has parts, and they always go in the same order. The first word is the program to run — ls, grep, cat. Everything after it is a list of words the shell hands to that program, split on spaces, for the program to interpret however it likes.
Those words come in two kinds. A positional argument is a plain word, usually the thing the command should act on — a filename, a directory, a search pattern. An option (also called a flag) is a word starting with a dash, like -l or --all, and it changes how the command behaves rather than naming what it acts on. So in ls -l projects, ls is the program, -l is an option asking for the long listing format, and projects is the positional argument saying which directory to list.
The order that matters is program first; options and arguments after it are mostly free to move, though each program decides its own rules. Getting this anatomy straight is what lets you read an unfamiliar command and guess what it will do before you run it — the dashed words tweak the behavior, the bare words are what it works on.
Moving around the filesystem
At any moment the shell has a current directory — one place in the filesystem tree it treats as where you are. Three commands are all you need to work that tree. pwd prints the current working directory as an absolute path from the root, so it answers "where am I" without ambiguity. ls lists the contents of a directory, the current one by default, so it answers "what is here".
The third command moves you. cd changes the current directory to the one you name, and from then on every relative path is read from that new place. Give it a directory name to step in, .. to step up to the parent, or an absolute path to jump straight there. Because a relative path is resolved from wherever you currently are, cd is what decides what a bare name like notes.txt even points at.
Between the three, driving the filesystem is a rhythm: pwd to confirm where you stand, ls to see the choices, cd to move, then ls again. It is the same directory tree that any file manager shows, walked by typing instead of clicking.
Reading files and finding things
Most of what you do at a shell is look, not change. cat prints a file's contents straight to the terminal — fine for something short, and the quickest way to see what a file holds. For anything longer, less shows the file one screenful at a time so it does not scroll past you, and you page through it and quit when done.
Two more commands answer the questions "where is the text" and "where is the file". grep searches through text for a pattern and prints the lines that match, which turns a large file into just the parts you care about. find searches a directory tree for files by name (and by other traits), so you can locate something without remembering exactly which folder you left it in.
None of these commands alter what they read; they only report. That is what makes them safe to reach for first — when something is wrong, the honest move is to look before you touch, and cat, less, grep, and find are how you look.
Sending output to a file
By default, whatever a command prints goes to the terminal — that stream of output is what the later processes concept calls standard output, and normally it lands on your screen. Redirection reroutes it. Put > and a filename after a command and its output goes into that file instead of the terminal, silently, with nothing shown on screen.
There are two forms, and the difference matters. > overwrites: it replaces the file's contents with the new output, discarding whatever was there. >> appends: it adds the new output to the end, keeping what the file already held. Reach for > to capture a fresh result and >> to accumulate results across several commands, and keep them straight — an accidental > on the wrong file throws away its old contents.
Redirection is how a command's output stops being something you glance at and becomes something you keep: a saved log, a generated list, a file another program will read later. The command does not know or care that its output went to a file rather than the screen; the shell handled the rerouting on its own.
Chaining commands with a pipe
A pipe wires two commands together. Write | between them and the first command's output, instead of going to the terminal, becomes the second command's input. Those two streams — the output one command produces and the input the next one reads — are exactly what the later processes concept calls standard output and standard input; a pipe simply connects one to the other.
That connection is what makes small commands add up. Each program does one narrow job and reads and writes a plain stream of text, so you can chain them: ls | grep report lists a directory and passes that listing to grep, which prints only the lines mentioning report. Add another | and a third command transforms the result again, and there is no limit to how long the chain grows. It works like an assembly line where each station does one small job and hands its result straight to the next station — each command takes what the one before it produced, does its single job, and hands the result straight on.
The payoff is that a few general-purpose tools recombine into an enormous number of specific answers, without writing or saving a program. The pipe symbol is | on every mainstream shell, Unix and PowerShell alike, which is why "compose small commands with a pipe" is the same skill everywhere you will use it.
The shell is how you drive a server
A server usually has no screen and no mouse. When you reach one — the machine behind a personal site, a game server, a shared team tool — what you get is a shell prompt, and the typed command line is the whole interface. Every capstone here that touches a server is operated this way, so the handful of commands for moving around, reading files, and routing output is not a beginner detour; it is the day-to-day control panel.
The deeper payoff is composition. Because each command does one small job and pipes hand output straight along, a short chain of general-purpose tools does work that would otherwise need a written, saved, and debugged program. Counting matching lines, filtering a log, finding the one file out of thousands — these are one line at a prompt, not a project.
That is the real reason to be fluent here. Driving a computer by typing is faster than clicking once you know the words, it works the same over a remote connection as it does locally, and it turns "I need a quick answer from this machine" into something you type in a few seconds and read back.