The shell

Navigating a filesystem from a terminal, pipes, redirection.

Check your own machine

These commands only read information — they change nothing. Run the block for your OS, then use the table to read your own numbers against the ideas above.

Windows

Which shell am I running PowerShell

$PSVersionTable.PSVersion

What you should see A version table showing the running PowerShell version as Major, Minor, Build, and Revision numbers.

List the current directory PowerShell

Get-ChildItem

What you should see The items in the current directory, with columns for mode, last write time, length, and name.

Chain two commands with a pipe PowerShell

'hello world' | Measure-Object -Word

What you should see A table reporting Words : 2 — the string is piped into Measure-Object, which counts two words.

Note PowerShell uses | for pipelines just as Unix shells do; the counting tool differs (Measure-Object rather than wc).

macOS

Which shell am I running zsh

echo $SHELL

What you should see The path of your login shell, usually /bin/zsh, since zsh is the macOS default.

Note macOS has defaulted to zsh since Catalina (10.15), released 2019; $SHELL reports the login shell, not necessarily the shell currently running.

List the current directory zsh

ls

What you should see The names of the files and directories in the current directory, exactly as on Linux.

Chain two commands with a pipe zsh

echo hello world | wc -w

What you should see 2 — echo prints hello world, the pipe sends that output into wc -w, which counts two words.

Linux

Which shell am I running bash

echo $SHELL

What you should see The absolute path of your login shell, typically /bin/bash on most Linux distributions as of 2026.

Note $SHELL reports the login shell set at login, which is not necessarily the shell currently running in this terminal.

List the current directory bash

ls

What you should see The names of the files and directories in the current directory.

Chain two commands with a pipe bash

echo hello world | wc -w

What you should see 2 — echo prints hello world, the pipe sends that output into wc -w, which counts two words.

Where each idea shows up in your output
Concept	Windows	macOS	Linux
Which shell (or version) is running	$PSVersionTable.PSVersion	echo $SHELL	echo $SHELL
List the current directory	Get-ChildItem	ls	ls
Count words by piping one command into another	'hello world' \| Measure-Object -Word	echo hello world \| wc -w	echo hello world \| wc -w

The same ideas, as prose

These are the exact fragments the model serves — also available as an ordered study guide.

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 broken into its parts: the first word is the program to run, a dash-prefixed word is an option that changes its behaviour, and a plain word is a positional argument naming what to act on.

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

A command's output stream goes to the terminal by default, but redirection diverts that same stream into a file instead, where the greater-than sign overwrites and the double greater-than sign appends.

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 chains three commands: each reads a stream as input and writes a stream as output, and the pipe symbol wires one command's output to the next command's input, narrowing the stream stage by stage.

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.