Foundations roadmap

Command line basics

Log in to save this

Saving keeps this in your list across devices. It's a free account — no card.

You don't need to become a shell wizard. You need enough command-line fluency to follow any tutorial, README, or team workflow that says "run this" — which is nearly all of them. A handful of commands and one core idea, that the terminal is always standing in some folder, get you most of the way.

Where am I? The working directory

A terminal is always "in" one folder, called the working directory. Every command you type runs relative to it. Most command-line confusion comes from being in a different folder than you think.

pwd              # print the folder you're in
ls               # list what's in it
cd projects      # move into a subfolder
cd ..            # move up one level
cd ~             # go to your home folder

Paths come in two kinds. An absolute path starts from the root, like /home/sam/projects, and works from anywhere. A relative path, like projects/app, is interpreted from wherever you are now. . means the current folder and .. means its parent.

On Windows, PowerShell accepts cd, ls, and pwd too; the older Command Prompt uses dir instead of ls. WSL or Git Bash lets you follow Unix-style tutorials exactly.

Creating, moving, and deleting

A few commands cover almost all file management:

mkdir notes                 # make a folder
mkdir -p app/src/components # make nested folders at once
touch notes/todo.md         # create an empty file
cp todo.md backup.md        # copy
mv draft.md final.md        # move, or rename in place
rm old.md                   # delete a file
rm -r old-folder            # delete a folder and its contents

Two things surprise beginners. First, mv is both "move" and "rename": moving a file to a new name in the same folder renames it. Second, rm does not use the trash. Deleted files are gone, with no undo. Before running rm -r, run pwd and ls to confirm you're deleting what you mean to delete.

Without -p, mkdir app/src fails if app doesn't exist yet.

Anatomy of a command

Most commands follow the same shape:

command  -flags  arguments
ls       -la     projects

The command is the program to run. Flags (options) change how it behaves; -l gives a long listing and -a includes hidden files like .gitignore. Arguments tell it what to act on.

The shell splits what you type on spaces, so a folder named My Projects looks like two separate arguments. Wrap it in quotes: cd "My Projects". This is also why developers tend to name folders with dashes, like my-projects.

When you forget how a command works, ask it: man ls on macOS/Linux (or ls --help on Linux), and Get-Help in PowerShell. Press Tab to autocomplete file and folder names, which avoids typos.

Running programs and scripts

The terminal is how you run your own code and tools:

node index.js      # run a JavaScript file with Node
npm run dev        # run a script defined in package.json
./setup.sh         # run a shell script in the current folder

The file argument is relative to your working directory, so node index.js only works from the folder containing index.js.

A script run as ./setup.sh must be marked executable. If you get "Permission denied," run chmod +x setup.sh once, or run it with bash setup.sh.

Some programs, like dev servers, keep running and hold on to the terminal. Press Ctrl+C to stop them, or open a second terminal tab to keep working while the server runs.

When a command fails, read the message

Error messages look intimidating but usually say exactly what's wrong. Read the last lines slowly:

  • "command not found" — the program isn't installed, isn't on your PATH, or is misspelled.
  • "No such file or directory" — the path doesn't exist from where you are. Check pwd and ls.
  • "Permission denied" — you lack permission, or a script isn't executable.
  • "Cannot find module '/home/sam/index.js'" — Node looked for the file in the path shown; compare it with where your file actually is.

The habit that fixes most problems: run pwd, run ls, and compare what you see with what the command expected. Copying an exact error line into a search engine also works far better than describing the problem in your own words.

Try it: a five-minute drill

Do this without touching your mouse or file explorer:

cd ~
mkdir -p cli-practice/src
cd cli-practice
touch src/app.js notes.md
mv notes.md README.md
ls -la
cd src
pwd
cd ..
rm -r src
ls

Before each command, predict what it will do; after it, check with pwd or ls. Then pick any project README you've seen and follow its setup steps from the terminal. When you can do that without guessing which folder you're in, you have what you need.