The Command Line

What "the command line" actually is

When you open a terminal, a program called a shell is waiting to read what you type. The most common shell is bash (or its cousin zsh, the macOS default — they behave almost identically for our purposes). You type a command, press Enter, the shell runs it, prints output, and waits for the next one. That's the entire loop.

A command has three parts:

Why the command line (when GUIs exist)

Navigating the filesystem

The filesystem is a tree of folders (directories). At any moment your shell sits "in" one directory — the working directory. Three commands cover all movement:

pwd            # print working directory — "where am I?"
ls             # list what's in this directory
ls -la         # list ALL (incl. hidden .files), long format (perms, size, date)
cd /tmp        # change directory to /tmp (an absolute path, starts at root /)
cd             # with no argument, go to your home directory (~)
cd ..          # go UP one level (.. means "parent")
cd -           # go back to the previous directory

Absolute vs relative paths trips up every beginner, so internalize it now:

Making & moving files

Let's create a small workspace and practice. Type these in order:

cd ~                       # start at home
mkdir -p cli-practice/data # make nested folders (-p makes parents as needed)
cd cli-practice
touch notes.txt            # create an empty file
echo "hello data" > data/greeting.txt   # write text into a new file
cp data/greeting.txt data/greeting-backup.txt   # copy
mv notes.txt README.txt    # move/rename
ls -R                      # list recursively to see the whole tree

Looking inside files

Data engineers stare at files constantly — peeking at a CSV, tailing a log. The toolkit:

cat data/greeting.txt     # dump the whole file to the screen
head -n 5 bigfile.csv     # first 5 lines (great for peeking at headers)
tail -n 5 bigfile.csv     # last 5 lines
tail -f app.log           # FOLLOW a log live as it grows (Ctrl-C to stop)
wc -l bigfile.csv         # count lines (rows) — your quick "how big is this?"
less bigfile.csv          # scrollable viewer; press q to quit, / to search

Pipes & redirection — where the shell gets powerful

This is the big idea. Two operators let small tools combine:

• | (pipe) — sends the output of one command as the input of the next.
• > and >> (redirect) — send output to a file (> overwrites, >> appends).

# How many lines mention "error" in a log?
cat app.log | grep "error" | wc -l

# Save the first 100 rows of a big CSV to a sample file
head -n 100 big.csv > sample.csv

# Append a line to a file without erasing it
echo "2026-06-21 run ok" >> run.log

A taste of data wrangling

Let's make a tiny CSV and answer questions about it with only the shell — no spreadsheet, no Python yet.

# create a small CSV
cat > data/sales.csv <<'EOF'
date,region,amount
2026-06-01,us,120
2026-06-01,eu,80
2026-06-02,us,200
2026-06-02,eu,95
EOF

wc -l data/sales.csv                 # how many lines (incl. header)?
head -n 1 data/sales.csv             # the header row
grep ",us," data/sales.csv           # only US rows
grep ",us," data/sales.csv | wc -l   # how many US rows?
cut -d, -f3 data/sales.csv | tail -n +2   # just the amount column, skip header

Survival kit

The handful of extras that make daily life smooth:

✓ Check yourself

Answer from memory before opening each one.

1. A script that reads data/sales.csv works when you run it from ~/cli-practice. Started from your home directory, the same script fails with "No such file or directory." Nothing was deleted. What happened, and what are two ways to fix it?

   Show answer

   data/sales.csv is a relative path, so it is resolved from the working directory — from home it means ~/data/sales.csv, which doesn't exist. Either cd ~/cli-practice first, or use a path that means the same place from anywhere, such as ~/cli-practice/data/sales.csv. See Navigating the filesystem.

2. A nightly job finishes with echo "2026-06-21 run ok" > run.log, with the date changing each night. After thirty nights, how many lines does run.log hold, and why?

   Show answer

   One — last night's. > overwrites the file every time it runs, so each night erases the history before writing its line; the log needed >>, which appends. See Pipes & redirection.

3. A partner sends an 8 GB CSV that your spreadsheet app refuses to open. What are your first two commands, and what does each one tell you?

   Show answer

   head -n 5 file.csv shows the header and a few rows instantly, because it reads only the top of the file instead of loading all of it; wc -l file.csv counts the lines, which is your row count (minus one for the header). Columns and size are the first things to know about any new dataset. See Looking inside files.

4. Using the data/sales.csv from this chapter, write one line that prints only the amounts for 2026-06-02. What exactly does it print?

   Show answer

   grep "2026-06-02" data/sales.csv | cut -d, -f3 prints 200 then 95. grep keeps the matching rows (the WHERE), the pipe hands them to cut, and cut keeps the third comma-separated field (the SELECT); the header never matches, so there is nothing to skip. See A taste of data wrangling.

5. The chapter counts US rows with grep ",us,". Next month the file gains rows for a new region, aus, and a colleague simplifies the pattern to grep "us". What happens to the US count, and why?

   Show answer

   It becomes too high: grep matches text anywhere in the line, and aus contains us, so every Australian row is counted as US. The commas pin the match to a whole field. It is a small case of a general rule — shell tools see lines of text, not columns, so you have to tell them where a value starts and ends. See A taste of data wrangling.

6. A teammate tidies the team's export folder every Friday by dragging files around in a file manager, and says the shell would be overkill. When are they right, and what would make you insist on a command instead?

   Show answer

   For a genuine one-off on their own laptop, clicking is fine. What decides it is repetition, reach and scale: a weekly task should be a saved command, because text can be versioned and re-run identically while clicks can't; a server or container has no GUI at all; and thousands of files are one line in the shell but an afternoon of dragging. A Friday ritual already fails the first test. See Why the command line.

# 1) data rows = total lines minus the header
tail -n +2 data/sales.csv | wc -l        # -> 4

# 2) count EU rows
grep ",eu," data/sales.csv | wc -l        # -> 2

# 3) save EU rows to a new file
grep ",eu," data/sales.csv > data/eu.csv
cat data/eu.csv                            # confirm

Takeaway

• A command is a program, flags that change its behavior, and arguments it acts on. The shell only reads the line and runs it.
• Relative paths start at the working directory and absolute paths start at the root, so run pwd before any command that changes files.
• rm has no undo, so read the path before you press Enter and never run rm -rf on a path you have not checked.
• A pipe feeds one command's output into the next, which lets small single-purpose tools do what no single app does. Data pipelines use the same idea.
• head, tail and wc -l let you meet a multi-gigabyte file without opening it.
• A saved command is repeatable and reviewable; clicking is not, which is why platform work lives in the shell.

Now make every change you type tracked and reversible with version control. → Git & GitHub

Further reading

• Shell Command Language — The Open Group, POSIX.1-2017. The standard that defines pipes, redirection and quoting across sh-compatible shells.
• POSIX Utilities — The Open Group, POSIX.1-2017. The portable behavior of ls, cp, mv, head, tail, wc, grep and cut.
• grep(1) — Linux man-pages project. Every grep option, including the recursive search used in the survival kit.
• Bash Reference Manual — GNU Project. The full reference for pipelines, redirection and history in bash.