The terminal / command line

Status: 🟩 COMPLETE Last updated: 2026-06-20 Plain-English tagline: A text box that runs programs. Looks intimidating, isn’t. Five minutes of learning here pays back ten thousand times over.


In plain English

A terminal is a window on your computer that lets you type commands and see text responses. Instead of clicking buttons and dragging things, you type the name of a program and press Enter. The program runs and prints its output back to you.

Everything you can do by clicking around in File Explorer or Finder, you can also do from the terminal. And a lot more. Almost every development tool — Git, Node.js, npm, Claude Code, the Vercel CLI, the Supabase CLI — is operated from the terminal.

People who haven’t used it often find it intimidating. The blinking cursor on a blank black screen feels like it’s daring you to make a mistake. But the terminal is just another input method — like a steering wheel vs a touchscreen. Once you’ve spent an hour with it, the fear goes away and the speed it gives you becomes addictive.


Why it matters

  1. Most modern dev tools are CLI-first. They might have GUIs, but the terminal is where everything works most reliably and where tutorials are written.
  2. Claude Code lives in the terminal. The AI agent we use to build things is itself a CLI program. Knowing how the terminal works lets you understand what Claude is doing when it runs commands.
  3. Servers don’t have GUIs. When something breaks on a deployed server, the only way to look around is the terminal — usually over SSH (a way to remotely log in).
  4. It’s faster. For repetitive operations, typing is faster than clicking. Pros do everything in the terminal because they have to do it 100 times a day.

Terminal vs shell — different things, often confused

Two distinct words you’ll see used interchangeably:

WordWhat it is
TerminalThe program that shows you the window where you type — e.g. Windows Terminal, Apple Terminal, iTerm2, Warp
ShellThe language that interprets what you type — e.g. PowerShell, Bash, Zsh, Fish, Cmd

A terminal can usually run any shell. When you open Windows Terminal, you choose which shell to start (PowerShell, Bash, Cmd, etc.) — they all open in the same terminal program but interpret commands differently.

It’s like the difference between a notebook and the language you’re writing in. The notebook (terminal) holds the words. The language (shell) determines whether they’re English or French.

For day-to-day purposes, you can treat “terminal” as referring to both. People do this constantly. But when something behaves differently than a tutorial expects, the difference probably matters and you should check which shell you’re in.


The major shells

PowerShell (Windows default)

The modern Windows shell. Powerful, object-oriented (passes structured data through pipes, not just text). Verbose syntax (Get-ChildItem instead of ls). Default on every Windows install.

Versions: Windows PowerShell 5.1 (old, still installed) and PowerShell 7+ (cross-platform, newer). They behave slightly differently. Most Windows defaults still use 5.1.

Bash / Zsh (macOS and Linux default)

The classic Unix shells. Bash on most Linux, Zsh on modern macOS. Very widely used; most internet tutorials assume Bash syntax. Concise (ls instead of Get-ChildItem).

Cmd (legacy Windows)

The ancient DOS-style Windows shell. Don’t use it for new work; only relevant for very old Windows scripts.

Git Bash (Windows)

A Bash environment that ships with Git for Windows. Lets Windows users run Bash commands. Lower-fidelity than real Bash on Linux but good enough for most tutorials.

WSL (Windows Subsystem for Linux)

A full Linux environment running inside Windows. Real Bash, real Linux tools, talking to the Windows file system. Many serious Windows developers run their entire dev stack inside WSL to avoid Windows-specific quirks.

For your setup, George, you’re using PowerShell as the default in Claude Code, and the Bash tool when commands need POSIX syntax. The right choice depends on the command. Claude Code knows when to use which.


The anatomy of a command

Most commands follow the same shape:

program-name  argument1  argument2  --flag1  --flag2 value

Concrete example:

git commit -m "fix the bug" --no-edit
  • git — the program
  • commit — the subcommand (Git has many subcommands: commit, push, pull, etc.)
  • -m "fix the bug" — a flag (-m) with a value ("fix the bug")
  • --no-edit — a flag that doesn’t take a value

Conventions:

  • Single-letter flags start with one dash: -m, -h, -v
  • Long-form flags start with two dashes: --message, --help, --version
  • Most commands accept --help to print usage info
  • Arguments with spaces need quotes: "a phrase with spaces"

The dozen commands worth knowing immediately

These are commands you’ll use constantly. Most have Bash names; PowerShell often has equivalents with different names but also accepts the Bash names as aliases.

CommandWhat it does
pwdPrint working directory — where am I?
lsList the contents of the current folder
cd pathChange directory to path
cd ..Go up one level
cd ~Go to your home directory

Working with files

CommandWhat it does
cat file.txtPrint the contents of file.txt (PowerShell: Get-Content)
mkdir new-folderMake a new folder
touch new-file.txtCreate an empty file (PowerShell: New-Item new-file.txt)
cp source destCopy a file (PowerShell: Copy-Item)
mv source destMove or rename a file (PowerShell: Move-Item)
rm file.txtDelete a file (PowerShell: Remove-Item) — no undo
rm -rf folderDelete a folder and everything in it — dangerous, no undo

Information

CommandWhat it does
which commandShow where a command lives (PowerShell: Get-Command)
--versionShow a program’s version (e.g. node --version)
--helpShow a program’s help (e.g. git --help)

Project work

CommandWhat it does
npm installInstall dependencies from package.json
npm run devRun the project’s dev script
npm run buildRun the project’s build script
git statusWhat changed in this git repo?
git commit -m "msg"Save changes with a message

Misc essentials

CommandWhat it does
clearWipe the visible screen (Ctrl+L is the keyboard shortcut)
historyShow what you’ve typed recently
exitClose this shell

Special characters you’ll see

CharacterMeaning
.The current directory
..The parent directory
~Your home folder (e.g. C:\Users\georg\ on Windows)
/Path separator on Mac/Linux; works in PowerShell too
\Path separator on classic Windows; awkward to type in shells (needs escaping)
|Pipe — send the output of one command into another
>Redirect output to a file (overwrites)
>>Append output to a file
&&Run the next command only if the previous succeeded (Bash; PowerShell 7+)
;Run the next command regardless
*Wildcard — matches any characters in a filename (ls *.md lists all markdown files)
#Comment — everything after this on a line is ignored (Bash)
$VARRead environment variable VAR

Pipes — the superpower

The pipe character | is one of the most powerful ideas in shells. It connects two commands: the output of the first becomes the input of the second.

ls | grep "test"

This lists all files (output of ls), then filters that list for ones containing “test” (input to grep). The result: just the test-related files.

You can chain pipes:

git log --oneline | head -20 | sort

“Show the git log → take the first 20 lines → sort them alphabetically.”

Pipes turn small specialized programs into a giant toolbox by combining them in any way you need.


Environment variables

Variables that are available to every program you run from the shell. Used heavily for configuration and secrets.

# Bash
echo $HOME            # prints your home directory
export FOO=bar        # set a variable for this shell session
echo $FOO             # prints "bar"
# PowerShell
$env:HOME             # read
$env:FOO = "bar"      # set
echo $env:FOO         # prints "bar"

The most relevant env vars for development:

  • PATH — list of folders where the shell looks for commands. When you type git, the shell scans PATH to find the git program.
  • HOME (Bash) or USERPROFILE (Windows) — your home directory
  • NODE_ENV — typically development or production; many tools check this

.env files — text files in your project — are read by tools like Next.js and turned into env vars at runtime. They never set system-wide env vars.


Tab completion — the second superpower

Every modern shell has tab completion: start typing something, press Tab, and the shell tries to complete it.

  • Type cd Docu then Tab → completes to cd Documents
  • Type git che then Tab → completes to git checkout (in shells with Git completion)
  • Type nextjs/app/p then Tab → completes to nextjs/app/page.tsx

If multiple completions are possible, press Tab twice to see the options. Use this constantly — it saves typos and is much faster than typing full paths.


Command history

Press the Up arrow to recall previous commands. Press it repeatedly to go further back. Press Down to come forward.

Ctrl+R (Bash) starts a reverse search — type a few letters and it finds the most recent matching command.

PowerShell has Get-History and Invoke-History (with the alias r) for managing history.


A concrete example: making a Next.js project from scratch

# 1. Move into your projects folder
cd C:\Users\georg
 
# 2. Create a new Next.js project
npx create-next-app@latest my-cool-app --typescript --tailwind --app
 
# 3. Move into the new project
cd my-cool-app
 
# 4. Install a library
npm install @supabase/supabase-js
 
# 5. Start the dev server (Ctrl+C to stop)
npm run dev
 
# 6. In another terminal, check it's running
curl http://localhost:3000

Six commands. New project ready to develop. The equivalent in a GUI would be ~30 clicks.


Common gotchas

  • rm -rf is permanent. No recycle bin. No undo. Triple-check the path before pressing Enter — especially if it contains a wildcard.

  • PowerShell and Bash have different syntax in surprising places.

    • Bash environment variables: $VAR. PowerShell: $env:VAR.
    • Bash command chaining: && works everywhere. PowerShell 5.1: doesn’t support && (use ; or if ($?) {...}).
    • Bash here-docs: <<EOF ... EOF. PowerShell: @'...'@ (single-quoted) or @"...""@ (double-quoted).
  • Quotes matter. 'single quotes' are literal (no variable substitution). "double quotes" interpolate variables. `backticks` execute the contents and substitute the result (Bash only — PowerShell uses backticks for line continuation).

  • The dollar sign in PowerShell prompts is part of the prompt, not the command. Don’t type the $ when copying examples — it’s just a marker indicating “this is a shell prompt.”

  • Path separators. Bash uses /. Windows traditionally uses \. PowerShell accepts both and modern Node tools accept both. Some scripts break on Windows due to / vs \ confusion.

  • Spaces in folder names. Always quote paths with spaces: cd "Program Files", not cd Program Files.

  • Case sensitivity. Linux is case-sensitive (README.md ≠ readme.md). Mac and Windows usually aren’t, by default. If your code works locally but fails on Vercel (which runs Linux), check case.

  • The terminal’s font. Most default monospaced fonts can’t distinguish 1 from l, or 0 from O. Install a programming font (Cascadia Code, JetBrains Mono, Fira Code, Berkeley Mono) for sanity.

  • Closing the terminal kills running programs. If you start npm run dev in a terminal and close the terminal, the dev server dies. Either keep the terminal open or use a tool like pm2 / systemd / vercel dev for long-running processes.

  • The dot-slash thing. ./command runs a script in the current directory; command looks in PATH. On Bash you sometimes need the dot-slash explicitly; PowerShell is less strict.

  • Don’t run untrusted commands. Copy-pasting from random Stack Overflow answers can be dangerous. curl ... | sh is a common pattern but it executes whatever code the server sends — read what you’re running.


See also


Sources