Linux Crash Course

Kickoff — the basic concepts, before you need them

Before you start clicking through

This is a map, not the material. Four written parts carry the actual depth — worked examples, the exceptions, what breaks and why:

• Part 1 — The command line
• Part 2 — Installing and managing tools
• Part 3 — Git and GitHub
• Part 4 — Files you will meet

Only Part 1 gates a first practical. If you are short on time, read that one properly and treat the rest of this deck as a preview of what is coming.

If presenting live: say this out loud before moving on. The deck is deliberately thin — if a question digs into detail, that is what the corresponding part is for, not a reason to improvise an answer here.

Why a terminal at all?

A fair question before spending an evening on this.

• The tools only exist there. Most scientific software has no graphical interface — and a program that runs from a command line can be run a thousand times by another program. One that needs a human to click cannot.
• It is a record. A command can be pasted into a methods section, rerun next year, and checked by someone else. A sequence of clicks cannot.
• It scales without changing. The command that handles one file handles four hundred, unmodified.

The cost: nothing is discoverable. A terminal shows a cursor and waits. That gap is what Part 1 closes.

Part 1 — The command line

Reading the prompt

Own figure.

The one part worth watching is where you currently are — it changes as you move, and it answers the question that causes most early confusion.

The filesystem is one tree

Own figure.

No drive letters. Everything — a second disk, a USB stick, a network share — is a directory somewhere inside this one tree. And it is case-sensitive: Data.csv and data.csv are two different files.

Moving around

mkdir -p demo && cd demo
pwd
echo "hello" > notes.txt
ls -l

/home/user1/demo
-rw-r--r-- 1 user1 staff 6 Sep 26 07:08 notes.txt

pwd, ls and cd answer where am I and what is here — the two questions worth asking before anything else.

Press Tab. Every time, not just when stuck.

Typing a filename from memory is a guess. Letting the shell complete it is not — it is spelled right or it does not exist. This is worth repeating because it is the single most common thing people forget under time pressure.

Parameters change what a command does

printf "alpha,12\nbeta,7\ngamma,103\n" > scores.csv
sort -t, -k2 -n -r scores.csv

gamma,103
alpha,12
beta,7

Four parameters, four jobs: -t, the delimiter, -k2 which column, -n compare as numbers, -r largest first. Drop -n and 103 sorts before 12, because as text it starts with a smaller character.

Never put a space in a name you create

The shell splits what you type on whitespace — so a space inside a filename is indistinguishable from a space between two separate arguments.

cd lab notebook
bash: cd: lab: No such file or directory

cd saw two arguments, not one. Quoting (cd "lab notebook") fixes it, but the real fix is upstream: use lab_notebook and the problem never comes up. Graphical file managers and Windows both allow spaces freely — the terminal is where that difference first bites.

Pipes: small tools, chained

printf "banana\napple\ncherry\napple\n" | sort | uniq -c | sort -rn

      2 apple
      1 cherry
      1 banana

Read left to right, as a sentence: sort it, count the repeats, sort that numerically. None of these four tools knows the others exist — the pipe is what turns simple pieces into an answer nobody wrote a program for.

Wildcards, briefly

mkdir -p logs && touch logs/a.log logs/b.log logs/notes.txt
ls logs/*.log

logs/a.log
logs/b.log

* matches any run of characters. Check what it will match with ls before ever pointing it at rm.

Part 1, in one line

Terminal, tree, parameters, pipes, wildcards. The full page → has the backslash line-continuation, stdin/stdout/stderr, reading errors, a short section on $HOME-style variables, and a checklist to test yourself against.

Part 2 — Installing and managing tools

The problem environments solve

Two projects can genuinely need different, incompatible versions of the same dependency. An environment keeps one project’s tools from breaking another’s — and if it is written down in a file, someone else can rebuild it and get the same result.

pixi init myproject && cd myproject
pixi add python samtools
pixi run python --version

No “activation” — pixi run uses this project’s tools because you are standing in this project’s directory.

Not executed: installing needs the network and takes minutes. The full page runs through this properly, plus the conda/mamba translation table for when someone hands you instructions written the old way.

Part 2, in one line

pixi.toml says what you asked for; pixi.lock says exactly what you got. Commit both. The full page → covers conda and mamba too — you will meet both in documentation even if you never install them.

Part 3 — Git and GitHub

Four stages, one command between each

Own figure.

git config --global user.name "You"          # one-time, per machine
git config --global user.email "[email protected]"

mkdir -p repo && cd repo && git init -q
echo "print('hello')" > analysis.py
git add analysis.py
git commit -q -m "Add the analysis script"
git log --oneline

9c1f2ab Add the analysis script

Branches, and the error you will actually see

If a team shares one repository, this happens in the first hour:

 ! [rejected]        main -> main (fetch first)

Nothing is lost — Git is refusing to overwrite someone else’s work with yours. The fix, and the habit worth having from the start: work on a branch, push it, and open a pull request for someone to read before it joins main.

The GitHub side (pushing a branch, the Compare & pull request button) is prose on the full page, not a command — it is an interactive web UI and the exact buttons move, so it is described as “what to look for,” not a fixed click path.

Your GitHub profile is worth curating

You will need an account. At least one person per team, for the shared repository to exist — in practice, everyone, since each of you pushes your own commits.

Treat it as more than a requirement: pinned repositories, a short bio, a clear README on each project — this becomes a portfolio you did not realise you were building. One real example: github.com/jonas-fuchs.

For a job in this field, that can say more than a CV — it is evidence you can do the work, not a claim that you can.

Worth slowing down on if presenting live — this is a genuinely useful thing for a UAS bioinformatics cohort to hear early, not a footnote. It does not need to happen this semester; it needs to start.

Part 3, in one line

add → commit → push, and branch before you push if anyone else shares the repository. The full page → covers diff, restore, merge conflicts, and the full branch-to-pull-request walkthrough.

Part 4 — Files you will meet

Two formats you cannot avoid

cat > README.md <<'EOF'
# My project
A short description, a `code` span, and a [link](notes.md).
EOF

python3 -c "
import json
d = {'sample': 'A1', 'passed': True, 'count': 1420}
print(json.dumps(d))
"

{"sample": "A1", "passed": true, "count": 1420}

Markdown is what READMEs and GitHub pages are written in. JSON is how tools hand structured results to each other — six types, no comments, no trailing commas.

Part 4, in one line

Plus CSV/TSV, why Excel silently damages data files, and the two invisible things — line endings and encoding — that make a text file misbehave. The full page →

Before your first practical

What to actually do this week

• Open a terminal. On Windows, install WSL2 first — do it on a quiet evening, not ten minutes before a session.
• Work through Part 1 properly, and check yourself against its list at the end.
• Install VS Code — and on Windows, its Remote – WSL extension.
• Come back to Parts 2–4 when you actually need them. Nobody expects them memorised in advance.

If presenting live, this is the slide to slow down on — it is the one with an action attached, unlike everything before it.