Use the terminal with confidence, track your work with Git, and collaborate on GitHub with pull requests.

Git & the Command Line

Open a terminal: Terminal on macOS or Linux, Git Bash or a WSL Ubuntu terminal on Windows.

Run ls, then ls -a, and compare: which hidden entries (starting with a dot) appear?

Create the practice folder with mkdir ~/cli-practice and go into it with cd ~/cli-practice. Run pwd to confirm.

Go up with cd .., then back in using Tab completion: type cd cli and press Tab.

Try an absolute path: cd /tmp, then pwd, then cd - to jump back.

Press the Up arrow a few times to browse your history, then run clear.

Open the manual for ls (man ls, or ls --help in Git Bash) and find what the -t option does. Press q to quit.

## Why it matters

Graphical apps are great for everyday work, but much technical work happens in a **terminal**: running code, using Git, connecting to servers, installing tools, automating repetitive tasks. Servers in the cloud usually have no desktop at all. Being comfortable at the command line is one of the clearest signs of a working developer, data scientist, or security or cloud engineer.

## Terminal, shell, command

- The **terminal** is the window you type into.
- The **shell** is the program that reads your command and runs it. This course uses **bash** or **zsh**; the commands here work the same in both.
- A **command** is a program name, often followed by **options** (flags such as `-l`) and **arguments** (such as a folder name): `ls -l Documents`.

## Opening one

- **macOS:** open *Terminal* (Spotlight: Cmd+Space, type "Terminal"). The default shell is zsh.
- **Linux:** open *Terminal* from your apps menu (often Ctrl+Alt+T). The default shell is usually bash.
- **Windows:** install **Git for Windows** from git-scm.com, which includes **Git Bash**, a bash terminal. Or install **WSL** (Windows Subsystem for Linux: run `wsl --install` in an administrator PowerShell, then restart) to get a full Ubuntu terminal. Both work for this course. The built-in Command Prompt and PowerShell use different commands, so use Git Bash or WSL here.

You will see a **prompt**, something like `alex@laptop ~ %` or `alex@laptop:~$`. It is waiting for a command. Type one and press Enter.

## Where am I? `pwd`

The terminal is always "in" one folder (directory), the **working directory**. `pwd` (print working directory) shows it:

```bash
$ pwd
/Users/alex
```

On Linux and WSL it looks like `/home/alex`; in Git Bash, `/c/Users/alex`. The `$` here just stands for your prompt; do not type it.

## What is here? `ls`

```bash
$ ls
Desktop  Documents  Downloads  Pictures
$ ls -l          # long format: permissions, size, date
$ ls -a          # include hidden files (names starting with .)
$ ls -la Documents
```

Text after `#` is a comment and is ignored by the shell.

## Moving: `cd`

```bash
$ cd Documents        # go into Documents (relative path)
$ cd ..               # up one level
$ cd ~                # home folder (plain cd does the same)
$ cd /tmp             # absolute path, starts at the root /
$ cd -                # back to the previous folder
```

- An **absolute path** starts with `/` (or `~`, which means your home folder) and works from anywhere.
- A **relative path** starts from where you are now. `.` means "this folder" and `..` means "the parent folder".
- Folder names with spaces need quotes: `cd "My Projects"`.

In WSL, your Windows files are under `/mnt/c/Users/<name>`. In Git Bash they are under `/c/Users/<name>`.

## Worked example

```bash
$ pwd
/Users/alex
$ ls
Desktop  Documents  Downloads
$ cd Documents
$ pwd
/Users/alex/Documents
$ cd ..
$ pwd
/Users/alex
```

## Time-savers

- **Tab completion:** type `cd Doc` and press Tab; the shell fills in `Documents/`. Press Tab twice to see options. This saves time and prevents typos.
- **History:** the Up arrow brings back earlier commands.
- **Cancel:** Ctrl+C stops a running command or clears the line.
- **Clear the screen:** `clear` or Ctrl+L.
- **Help:** `man ls` shows the manual (press `q` to quit). In Git Bash, use `ls --help`.

## Common mistakes

- Typing the `$` from examples.
- Wrong capitals: `documents` is not `Documents` on Linux (macOS usually ignores case, but do not rely on it).
- Spaces in names without quotes: `cd My Projects` tries to go into `My`.
- Not knowing where you are. When in doubt, run `pwd`.

## Quick recap

- The terminal runs a shell (bash or zsh); use Git Bash or WSL on Windows.
- `pwd` shows where you are, `ls` lists what is there, `cd` moves.
- Absolute paths start at `/` or `~`; relative paths start where you are.
- Tab completion, Up arrow and Ctrl+C make the terminal fast and safe.

## Try it

Open the **Do** tab to set up your terminal and practice folder.


Open a terminal on macOS, Linux or Windows and move around your folders with pwd, ls and cd.

Opening a terminal

How to Navigate the Terminal with Bash [5 of 20] | Bash for Beginners

Command Line Crash Course For Beginners | Terminal Commands

cd ~/cli-practice and create a project structure in one command: mkdir -p lab-project/data/raw lab-project/data/clean lab-project/docs

Create files: touch lab-project/data/raw/run1.csv lab-project/data/raw/run2.csv lab-project/docs/notes.txt

Write a line into a file with echo "Project started" > lab-project/docs/log.txt and display it with cat.

Copy run1.csv into data/clean, then rename the copy to run1-clean.csv with mv.

Copy the whole lab-project folder to lab-project-backup with cp -r, and list both with ls -R.

Create three junk files (touch a.tmp b.tmp c.tmp), preview them with ls *.tmp, then delete them with rm -i *.tmp.

Delete the backup folder: run pwd, preview with ls lab-project-backup, then rm -r lab-project-backup.

Run ls -R lab-project and check the final structure matches what you intended.

## Why it matters

Setting up a project, organising data files, cleaning up build output, moving logs on a server: all of it is file management, and the terminal does it faster and more repeatably than clicking. It is also less forgiving. The terminal has **no recycle bin**: a deleted file is gone. This lesson covers the commands and the habits that keep you safe.

**Safety rule for this course:** practise only inside `~/cli-practice`. Never use `sudo` for these commands, and never aim `rm` at your home folder or `/`.

## Making folders and files

```bash
$ cd ~/cli-practice
$ mkdir project                  # one folder
$ mkdir -p project/data/raw      # -p creates the parent folders too
$ touch project/notes.txt        # empty file (or updates its timestamp)
$ echo "first line" > project/todo.txt   # file with content (more on > next lesson)
```

## Looking at files

```bash
$ cat project/todo.txt     # print the whole file
first line
$ less bigfile.txt         # page through: Space = next page, q = quit
$ head -n 5 data.csv       # first 5 lines
$ tail -n 5 app.log        # last 5 lines
```

`cat` is fine for short files; use `less` or `head` for long ones.

## Copying: `cp`

```bash
$ cp project/todo.txt project/todo-backup.txt    # copy a file
$ cp project/todo.txt project/data/              # copy into a folder (keeps the name)
$ cp -r project project-copy                     # -r copies a folder and everything in it
```

## Moving and renaming: `mv`

`mv` does both. Moving to a new name in the same folder **is** renaming:

```bash
$ mv project/notes.txt project/meeting-notes.txt   # rename
$ mv project/todo-backup.txt project/data/          # move into a folder
```

Careful: if the destination file already exists, `cp` and `mv` **overwrite it without asking**. Add `-i` (interactive) to be asked first: `mv -i a.txt b.txt`.

## Deleting: `rm` and `rmdir`

```bash
$ rm project/data/todo-backup.txt   # delete a file, permanently
$ rmdir project/data/raw            # delete an EMPTY folder
$ rm -r project-copy                # delete a folder and everything inside
$ rm -i *.tmp                       # ask before each deletion
```

`rm -r` is the most dangerous everyday command. Before running it:

1. Run `pwd` to confirm where you are.
2. Run `ls` with the **same path or pattern** first (`ls project-copy`) to see exactly what would go.
3. Prefer specific paths over wildcards; use `-i` when unsure.

You will see `rm -rf` (force, no questions) in tutorials. Avoid it while learning.

## Wildcards

The shell expands patterns before the command runs:

| Pattern | Matches |
|---|---|
| `*.csv` | every name ending in `.csv` |
| `report-*` | names starting with `report-` |
| `data?.txt` | `data1.txt`, `dataA.txt` (exactly one character) |

```bash
$ ls *.csv          # preview first
$ mv *.csv data/    # then act
```

## Worked example: organise a messy folder

```bash
$ cd ~/cli-practice
$ mkdir -p tidy && cd tidy
$ touch jan.csv feb.csv mar.csv notes.txt draft.tmp old.tmp
$ mkdir data
$ ls *.csv
feb.csv  jan.csv  mar.csv
$ mv *.csv data/
$ ls *.tmp
draft.tmp  old.tmp
$ rm -i *.tmp
remove draft.tmp? y
remove old.tmp? y
$ ls -R
.:
data  notes.txt

./data:
feb.csv  jan.csv  mar.csv
```

`&&` runs the second command only if the first succeeds, so `cd tidy` only happens if `mkdir` worked. `ls -R` lists folders recursively.

## Common mistakes

- `rm` in the wrong folder. Check `pwd` first.
- A space in a path: `rm my file.txt` tries to delete two files, `my` and `file.txt`. Quote it: `rm "my file.txt"`.
- Overwriting with `mv`/`cp` by accident. Use `-i`.
- Copying a folder without `-r` (you get "is a directory" or "omitting directory").

## Quick recap

- `mkdir -p`, `touch` and `echo ... >` create; `cat`, `less`, `head`, `tail` view.
- `cp` copies (`-r` for folders); `mv` moves and renames.
- `rm` deletes permanently; `rm -r` deletes folders. Preview with `ls`, check `pwd`, use `-i`.
- Wildcards (`*`, `?`) select many files: always preview them first.

## Try it

Open the **Do** tab to build and reorganise a small project folder.


Create, view, copy, move, rename and delete files and folders from the terminal without losing anything by accident.

Creating and moving files

Linux/Mac Terminal Tutorial: Create, Copy, Move, Rename and Delete Files and Directories

cd ~/cli-practice and create app.log with the here-document from the reading (copy the whole block from cat to EOF).

Check the file: wc -l app.log should report 8 lines.

Count the errors with grep -c ERROR app.log (expect 3) and find the line number of the auth failure with grep -n auth app.log (expect 6).

Show every line that is not INFO with grep -v INFO app.log (5 lines).

Build the ranking pipeline step by step: grep ERROR app.log, then add | cut -d' ' -f4-, then | sort | uniq -c | sort -rn. Look at the output after each step.

Save the ranking with > error-report.txt, then append a title line with echo "Report for 2026-10-01" >> error-report.txt, and cat the file.

Capture an error: ls missing-file 2> errors.txt, then cat errors.txt.

Write one pipeline of your own that answers a question about app.log (for example, how many WARN lines mention a request).

## Why it matters

The real power of the command line is combining small tools. One line can find every error in a log, count them by type and save a report, on a file far too big to open in an editor. Developers use this to debug, data scientists to peek at datasets, and security engineers to sift logs for attacks.

## Streams: input, output, errors

Every command has three streams:

- **standard input** (stdin): what it reads, by default the keyboard,
- **standard output** (stdout): normal results, by default the screen,
- **standard error** (stderr): error messages, also the screen by default.

Redirection and pipes reconnect these streams.

## Redirection: send output to a file

```bash
$ ls > files.txt          # stdout to a file (creates or OVERWRITES it)
$ echo "more" >> files.txt  # append to the end instead
$ ls nothere 2> errors.txt  # stderr to a file
$ sort < names.txt          # read stdin from a file
```

`>` silently replaces the file's contents. Use `>>` when you want to add. Never redirect into the file you are reading: `sort data.txt > data.txt` empties `data.txt` before `sort` reads it.

## A practice log

Create this file in `~/cli-practice` (the `<<'EOF'` part is a "here document": everything up to `EOF` becomes the file):

```bash
cat > app.log <<'EOF'
2026-10-01 09:00:01 INFO server started
2026-10-01 09:02:13 WARN disk 80% full
2026-10-01 09:05:44 ERROR db timeout
2026-10-01 09:06:02 INFO request /home 200
2026-10-01 09:07:30 ERROR db timeout
2026-10-01 09:09:12 ERROR auth failed
2026-10-01 09:10:00 INFO request /login 200
2026-10-01 09:11:45 WARN slow request /search
EOF
```

## grep: find lines that match

```bash
$ grep ERROR app.log         # lines containing ERROR
$ grep -i error app.log      # ignore case
$ grep -n auth app.log       # show line numbers
6:2026-10-01 09:09:12 ERROR auth failed
$ grep -c ERROR app.log      # count matching lines
3
$ grep -v INFO app.log       # lines that do NOT match (5 lines)
$ grep -r "TODO" project/    # search every file in a folder
```

Put patterns with spaces or special characters in quotes: `grep "db timeout" app.log`.

## Pipes: output of one command into the next

The `|` (pipe) sends one command's stdout into the next command's stdin:

```bash
$ grep ERROR app.log | wc -l     # count error lines: 3
$ ls -l | less                   # page through a long listing
$ history | grep git             # find earlier git commands
```

Useful pipeline tools:

| Command | Does |
|---|---|
| `wc -l` | count lines |
| `sort` | sort lines (`-n` numeric, `-r` reverse) |
| `uniq -c` | collapse **adjacent** duplicates and count them (sort first) |
| `head -n 3` / `tail -n 3` | first / last lines |
| `cut -d' ' -f3` | pick field 3 of each line, splitting on spaces |

## Worked example: which errors happen most?

Build the pipeline one step at a time and look at the output after each step:

```bash
$ grep ERROR app.log
2026-10-01 09:05:44 ERROR db timeout
2026-10-01 09:07:30 ERROR db timeout
2026-10-01 09:09:12 ERROR auth failed
$ grep ERROR app.log | cut -d' ' -f4-
db timeout
db timeout
auth failed
$ grep ERROR app.log | cut -d' ' -f4- | sort | uniq -c | sort -rn
      2 db timeout
      1 auth failed
$ grep ERROR app.log | cut -d' ' -f4- | sort | uniq -c | sort -rn > error-report.txt
```

`-f4-` means "field 4 to the end". The last line saves the report instead of printing it. The same pipeline works on a million-line log.

## Common mistakes

- `>` when you meant `>>`, overwriting a file you wanted to keep.
- `uniq` without `sort` first, so non-adjacent duplicates are not merged.
- Forgetting quotes around patterns with spaces: `grep db timeout app.log` searches for `db` in two files named `timeout` and `app.log`.
- Writing one giant pipeline at once. Build it step by step.

## Quick recap

- `>` writes (overwrites), `>>` appends, `2>` captures errors, `<` reads from a file.
- `grep` finds lines: `-i`, `-n`, `-c`, `-v`, `-r`.
- `|` chains commands; `sort | uniq -c | sort -rn` is the classic "count and rank" pattern.

## Try it

Open the **Do** tab to analyse the practice log with pipelines.


Search text with grep, save output to files with redirection, and chain small commands into useful pipelines.

Pipes, grep, and redirection

How to Use Redirection and Pipelines in Bash [11 of 20] | Bash for Beginners

Linux/Mac Terminal Tutorial: The Grep Command - Search Files and Directories for Patterns of Text

Open a terminal on any system, navigate folders, manage files safely, and chain commands with pipes and grep.