Anhang 0 Teil 1: Terminal- und CLI-Grundlagen

March 2026 (7569 Words, 43 Minutes)

1. Warum dieser Anhang existiert

Wenn Sie sich jemals verloren gefühlt haben, als ein Dozent sagte “öffnen Sie ein Terminal und geben Sie diesen Befehl ein”, dann ist dieser Anhang für Sie.

Dieser Kurs verwendet das Terminal vom ersten Tag an. In Vorlesung 1 werden Sie Git installieren, Repositories klonen, Python einrichten und Ihre ersten Programme ausführen – alles über das Terminal. Diese Anleitungen setzen voraus, dass Sie bereits wissen, was ein Terminal ist, wie man durch Ordner navigiert und wie man Befehlssyntax liest.

Wenn Sie keinen informatischen Hintergrund haben, trifft diese Annahme möglicherweise nicht zu. Und das ist völlig in Ordnung. Viele professionelle Entwickler haben genau dort begonnen, wo Sie jetzt stehen.

Am Ende dieses Anhangs werden Sie:

• Verstehen, was ein Terminal ist und warum Entwickler es verwenden
• Den Unterschied zwischen einer Terminal-Anwendung, einer Shell und einem Betriebssystem kennen
• In der Lage sein, Ihr Dateisystem mit Textbefehlen zu navigieren
• Befehlssyntax wie git commit -m "my message" lesen und verstehen können
• Wissen, was PATH und Umgebungsvariablen sind (und “command not found”-Fehler beheben können)
• Verstehen, was ein Programm auf grundlegender Ebene tatsächlich ist
• Erkennen, warum Automatisierung durch Skripting eine Kernkompetenz im Software Engineering ist

Dies ist Vorab-Lektüre für den Kurs. Arbeiten Sie es in Ihrem eigenen Tempo durch, bevor oder parallel zu Vorlesung 1.

2. Was ist ein Terminal?

2.1 Das Terminal als Textgespräch mit Ihrem Computer

Ein Terminal ist eine textbasierte Schnittstelle, in der Sie Befehle eingeben und der Computer mit Text antwortet.

Stellen Sie es sich wie ein Chat-Gespräch vor:

Sie:       "Zeige mir alle Dateien in diesem Ordner"
Computer:  "document.txt  photo.jpg  notes.md"

Sie:       "Erstelle einen neuen Ordner namens 'project'"
Computer:  (erstellt den Ordner, sagt nichts -- Stille bedeutet Erfolg)

Sie:       "Wechsle in diesen Ordner"
Computer:  (verschiebt Sie dorthin, aktualisiert den Prompt, um Ihren neuen Standort anzuzeigen)

In der Praxis sehen die tatsächlichen Befehle so aus:

$ ls
document.txt  photo.jpg  notes.md

$ mkdir project

$ cd project

Das $-Zeichen ist der Prompt – es bedeutet “das Terminal ist bereit für Ihren nächsten Befehl.” Sie geben das $ nicht selbst ein.

Jedes Mal, wenn Sie eine Schaltfläche in einer grafischen Anwendung anklicken, führt die Anwendung im Hintergrund einen Befehl aus. Das Terminal ermöglicht es Ihnen, diese Befehle direkt auszuführen, ohne den grafischen Vermittler.

Kommt Ihnen das bekannt vor? Wenn Sie jemals ChatGPT, Claude oder GitHub Copilot verwendet haben, wissen Sie bereits, wie sich ein Textgespräch mit einem Computer anfühlt. Tatsächlich halten KI-Assistenten jetzt Einzug in das Terminal selbst – Tools wie GitHub Copilot CLI ermöglichen es Ihnen, in natürlicher Sprache zu beschreiben, was Sie möchten, und die KI übersetzt es in den richtigen Terminal-Befehl für Sie. Sie haben “GitHub Copilot CLI” im VS Code Terminal-Dropdown gesehen (Abschnitt 4.3) – genau das ist damit gemeint.

Warum also Terminal-Befehle lernen, wenn KI sie für Sie schreiben kann? Aus demselben Grund, warum Sie Mathematik lernen, obwohl es Taschenrechner gibt:

• Sie müssen verstehen, was die KI vorschlägt, bevor Sie es blind ausführen. Ein falscher Terminal-Befehl kann Dateien löschen, Arbeit überschreiben oder Ihr Projekt beschädigen.
• Sie müssen überprüfen und debuggen können, wenn etwas schiefgeht. Die KI hat nicht immer Recht, und wenn sie falsch liegt, müssen Sie die Fehlermeldung lesen und verstehen, was sie bedeutet.
• Sie brauchen mentale Modelle davon, wie das System funktioniert – PATH, Shells, Dateiberechtigungen – um der KI überhaupt gute Fragen stellen zu können.

KI macht das Terminal zugänglicher als je zuvor. Aber sie ersetzt nicht das Verständnis – sie verstärkt es. Im Laufe dieses Kurses werden Sie KI-Tools neben Terminal-Fähigkeiten einsetzen, und Sie werden sehen, wie viel effektiver die Kombination ist als jedes einzelne für sich allein.

2.2 Eine kurze Geschichte: Von physischen Terminals zu Software

In den 1960er und 1970er Jahren war ein “Terminal” ein physisches Gerät – eine Tastatur und ein Bildschirm (oder sogar ein Drucker), die mit einem großen Zentralcomputer verbunden waren. Benutzer gaben Befehle ein, und der Computer sendete Text zurück auf ihren Bildschirm.

Heute sind die physischen Terminals verschwunden, aber das Konzept überlebte als Terminal-Emulatoren – Softwareprogramme, die dasselbe textbasierte Gespräch simulieren. Wenn jemand sagt “öffnen Sie ein Terminal”, meinen sie das Öffnen eines dieser Programme.

Dies ist keine veraltete Technologie. Es ist das Fundament, auf dem die gesamte moderne Datenverarbeitung aufgebaut ist. Server, die Websites betreiben, Cloud-Infrastruktur, automatisierte Testpipelines, Deployment-Systeme – sie alle laufen über Textbefehle. Jeder professionelle Softwareentwickler, Systemadministrator, Data Scientist und DevOps-Ingenieur nutzt das Terminal täglich.

2.3 Warum verwenden Entwickler immer noch das Terminal?

Sechs praktische Gründe:

1. Geschwindigkeit – mkdir project && cd project && git init einzutippen dauert 3 Sekunden. Dasselbe mit Klicks zu erledigen dauert 30 Sekunden und erfordert viele Fenster.
2. Automatisierung – Sie können Befehle in einer Datei (einem “Skript”) speichern und erneut ausführen. Eine Folge von Mausklicks können Sie nicht speichern.
3. Präzision – ein Befehl tut genau das, was Sie ihm sagen. GUIs verstecken manchmal Optionen oder treffen Annahmen.
4. Reproduzierbarkeit – Sie können einen Befehl mit einem Kollegen teilen, indem Sie Text einfügen. Eine Folge von Klicks können Sie nicht einfügen.
5. Remote-Zugriff – Server haben selten grafische Oberflächen. Das Terminal ist die einzige Möglichkeit, mit ihnen zu interagieren.
6. Tool-Ökosystem – professionelle Tools wie Git, Python-Paketmanager (uv, pip), Linter (ruff) und Testrunner (pytest) sind primär für das Terminal konzipiert. Die grafischen Schaltflächen, die Sie in IDEs wie VS Code sehen, sind nur Wrapper um diese Terminal-Befehle.

Dieser letzte Punkt ist besonders wichtig für diesen Kurs. Software Engineering dreht sich nicht nur um das Schreiben von Code – es geht darum, das Ökosystem und die Infrastruktur zu verstehen, die den Code umgeben: Versionskontrolle, Abhängigkeitsverwaltung, automatisierte Tests, Code-Qualitätsprüfungen, Continuous Integration und Deployment. All dies lebt im Terminal. Wenn Sie das Terminal verstehen, verstehen Sie, wie die gesamte Software-Entwicklungspipeline funktioniert – nicht nur der Code-Editor in der Mitte.

Deshalb beginnt dieser Kurs hier: nicht mit einer Programmiersprache, sondern mit den Tools und Arbeitsabläufen, von denen jedes professionelle Softwareprojekt abhängt.

flowchart LR
    subgraph GUI["GUI-Arbeitsablauf"]
        A1[Datei-Explorer öffnen] --> A2[Zum Ordner navigieren]
        A2 --> A3[Rechtsklick → Neuer Ordner]
        A3 --> A4[Ordnernamen eingeben]
        A4 --> A5[Ordner öffnen]
        A5 --> A6[Rechtsklick → Neue Datei]
        A6 --> A7[Dateinamen eingeben]
    end

    subgraph CLI["Terminal-Arbeitsablauf"]
        B1["mkdir project && cd project && touch README.md"]
    end

    style GUI fill:#E8E8E8,stroke:#818390
    style CLI fill:#d8d6e8,stroke:#5A56A1

Der GUI-Arbeitsablauf erfordert 7 Schritte mit Mausnavigation. Der Terminal-Arbeitsablauf ist eine einzige Zeile.

3. Warum sieht das Terminal auf jedem Computer anders aus?

3.1 Betriebssysteme und ihre Standard-Terminals

Jedes Betriebssystem wird mit unterschiedlicher Terminal-Software ausgeliefert und verwendet eine andere Shell (die Sprache, die das Terminal spricht). Deshalb funktionieren Befehle, die auf dem Mac Ihres Freundes funktionieren, möglicherweise nicht auf Ihrem Windows-PC.

Wichtig: “Terminal” und “Shell” sind nicht dasselbe, auch wenn Leute (und sogar einige Softwarenamen!) diese Wörter austauschbar verwenden. Das Terminal ist das Fenster; die Shell ist die Sprache, die darin läuft. Diese Verwechslung ist so häufig, dass wir sie im Detail in Abschnitt 3.2 unten erklären. Beachten Sie vorerst, dass die Tabelle unten “Terminal-App” und “Shell” in verschiedenen Spalten aufführt – es sind tatsächlich verschiedene Dinge.

Beachten Sie, dass sogar das Prompt-Symbol unterschiedlich ist: PowerShell verwendet >, zsh verwendet % und bash verwendet $. Dies ist kosmetisch – sie dienen alle dem gleichen Zweck: “Ich bin bereit für Ihren nächsten Befehl.”

3.2 Die Terminal-Anwendung vs. die Shell

Dies ist eine Unterscheidung, die viele Anfänger verwirrt, aber sie ist wichtig:

• Die Terminal-Anwendung ist das Fenster, das Sie auf dem Bildschirm sehen. Sie kümmert sich um Textdarstellung, Farben, Schriftarten, Scrollen und Kopieren/Einfügen.
• Die Shell ist das Programm, das in diesem Fenster läuft. Sie interpretiert die Befehle, die Sie eingeben, und kommuniziert mit dem Betriebssystem.

Eine Analogie: Das Terminal ist das Telefon (das Gerät), und die Shell ist die Sprache, die Sie am Telefon sprechen. Sie können dasselbe Telefon benutzen, um Deutsch oder Englisch zu sprechen. Ebenso können Sie dasselbe Terminal-Fenster verwenden, um verschiedene Shells auszuführen.

flowchart TB
    A["👤 Sie (Befehle eingeben)"] --> B["Terminal-Anwendung\n(Windows Terminal, Terminal.app, GNOME Terminal)"]
    B --> C["Shell\n(bash, zsh, PowerShell)"]
    C --> D["Betriebssystem\n(Dateisystem, Programme, Hardware)"]

    style A fill:#d4eaf7,stroke:#88BEE7
    style B fill:#E8E8E8,stroke:#818390
    style C fill:#d8d6e8,stroke:#5A56A1
    style D fill:#e4d3e0,stroke:#972982

Wenn jemand sagt “öffnen Sie bash”, meint er “öffnen Sie eine Terminal-Anwendung, die die bash-Shell ausführt.” Wenn jemand sagt “öffnen Sie PowerShell”, meint er dasselbe, aber mit PowerShell als Shell.

Warum ist das so verwirrend? Weil einige Programme die Grenze in ihren Namen verwischen. “PowerShell” ist sowohl eine Shell (die Sprache) als auch eine Terminal-Anwendung (das blaue Fenster). “Git Bash” ist eine Terminal-Anwendung, die die bash-Shell ausführt. “Windows Terminal” ist eine Terminal-Anwendung, die PowerShell, Eingabeaufforderung oder bash ausführen kann. Die Benennung ist inkonsistent, weshalb das Verständnis der zugrunde liegenden Unterscheidung wichtiger ist als das Auswendiglernen von Produktnamen.

4. Mehrere Terminals auf demselben Computer

4.1 Windows: PowerShell, Eingabeaufforderung, Git Bash und WSL

Windows ist die verwirrendste Plattform, weil sie die meisten Optionen hat. Hier ist, was jede einzelne ist:

Eingabeaufforderung (cmd.exe) – Das älteste Windows-Terminal, das bis in die 1980er Jahre zurückreicht. Es verwendet eine eigene Befehlssyntax, die sich von bash unterscheidet. Befehle wie dir statt ls, type statt cat. Sie werden dies selten benötigen.

PowerShell – Der moderne Windows-Standard. Leistungsfähiger als die Eingabeaufforderung, verwendet aber eine eigene Syntax, die sich von bash/zsh unterscheidet. Zum Beispiel Get-ChildItem statt ls (obwohl ls als Alias funktioniert). PowerShell ist das, was sich öffnet, wenn Sie Windows Terminal starten.

Git Bash – Wird automatisch installiert, wenn Sie Git für Windows installieren. Es bietet eine bash-Shell unter Windows, sodass Befehle wie ls, cd, cat, grep genauso funktionieren wie unter Linux und macOS. Dies empfehlen wir für diesen Kurs, weil die überwiegende Mehrheit der Tutorials, Stack-Overflow-Antworten und Dokumentationen bash-Syntax verwenden.

WSL (Windows Subsystem for Linux) – Ein vollständiges Linux-System, das innerhalb von Windows läuft. Dies ist eine fortgeschrittene Option. Sie benötigen es nicht für diesen Kurs, aber es existiert, falls Sie ein vollständiges Linux-Erlebnis ohne Dual-Booting möchten.

In diesem Kurs verwenden Sie entweder Git Bash oder das integrierte VS Code Terminal (konfiguriert für Git Bash). Auf diese Weise funktionieren alle Befehle in den Vorlesungen und Übungen für Sie, unabhängig von Ihrem Betriebssystem.

4.2 macOS und Linux: Terminal-Optionen

macOS: Die integrierte Terminal.app mit zsh funktioniert einwandfrei. Einige Entwickler bevorzugen iTerm2 (ein Drittanbieter-Terminal mit mehr Funktionen), aber es ist nicht notwendig.

Linux: Das Standard-Terminal (GNOME Terminal unter Ubuntu, Konsole unter KDE) mit bash funktioniert sofort. Keine Konfiguration erforderlich.

Auf beiden Plattformen können Sie auch das integrierte VS Code Terminal verwenden, das die Standard-Shell Ihres Systems ausführt.

4.3 Das VS Code Terminal: Ein Terminal für alles

VS Code hat ein integriertes Terminal, das Sie in diesem Kurs intensiv nutzen werden. Es erscheint am unteren Rand des VS Code Fensters.

So öffnen Sie es:

• Drücken Sie Ctrl+` (Backtick, die Taste über Tab) unter Windows/Linux
• Drücken Sie Cmd+` unter macOS
• Oder gehen Sie zu Ansicht → Terminal in der Menüleiste

4.3.1 Was passiert im VS Code Terminal?

Das VS Code Terminal ist eine Terminal-Anwendung, die in VS Code integriert ist. Genau wie Windows Terminal oder GNOME Terminal benötigt es eine Shell, die darin läuft. VS Code erkennt, welche Shells auf Ihrem System installiert sind, und lässt Sie wählen, welche Sie verwenden möchten.

Wenn Sie auf den Dropdown-Pfeil (▾) neben der +-Schaltfläche im Terminal-Bereich klicken, sehen Sie eine Liste der verfügbaren Optionen. Auf einem typischen Windows-System könnte dies Folgendes umfassen:

Die zentrale Erkenntnis: Jede Option in dieser Liste öffnet das gleiche Terminal-Fenster, aber mit einer anderen Shell, die darin läuft. Dies ist die Unterscheidung zwischen Terminal und Shell in Aktion. Sie können sogar mehrere Terminal-Tabs nebeneinander geöffnet haben, die jeweils eine andere Shell ausführen.

4.3.2 Mehrere Terminal-Tabs

Beachten Sie, dass der untere Bereich des Terminal-Panels Tabs wie “pwsh” (PowerShell) und “bash” anzeigt. Jeder Tab ist eine separate Terminal-Sitzung, die ihre eigene Shell ausführt. Sie können:

• Einen neuen Tab erstellen: Klicken Sie auf + (verwendet die Standard-Shell) oder verwenden Sie das Dropdown, um eine bestimmte Shell auszuwählen
• Zwischen Tabs wechseln: Klicken Sie auf den Tab-Namen am unteren Rand
• Einen Tab schließen: Klicken Sie auf das Mülleimer-Symbol
• Die Ansicht teilen: Klicken Sie auf das Teilen-Symbol, um zwei Terminals nebeneinander zu sehen

4.3.3 Ihre Standard-Shell festlegen

Wenn Sie möchten, dass VS Code immer Git Bash statt PowerShell öffnet:

1. Drücken Sie Ctrl+Shift+P (Befehlspalette)
2. Geben Sie “Terminal: Select Default Profile” ein
3. Wählen Sie “Git Bash”

Ab jetzt wird jedes neue Terminal in VS Code Git Bash verwenden.

Probieren Sie es jetzt aus:

1. Öffnen Sie VS Code und drücken Sie Ctrl+`, um das Terminal zu öffnen
2. Schauen Sie auf den unteren Rand des Terminal-Panels – welche Shell läuft? (Es zeigt “pwsh” für PowerShell oder “bash” für Git Bash)
3. Klicken Sie auf den Dropdown-Pfeil neben der +-Schaltfläche – sehen Sie die Liste der verfügbaren Shells
4. Öffnen Sie ein Git Bash-Terminal aus dem Dropdown
5. Jetzt haben Sie zwei Tabs am unteren Rand. Versuchen Sie, echo $SHELL im bash-Tab und echo $PSVersionTable im PowerShell-Tab einzugeben – verschiedene Shells, verschiedene Befehle, dasselbe VS Code Fenster
6. Setzen Sie Git Bash als Standard (Ctrl+Shift+P → “Terminal: Select Default Profile” → Git Bash)

Mehr zur VS Code-Einrichtung finden Sie in Vorlesung 1, Abschnitt 7: IDEs.

5. Bash vs. Zsh: Was ist der Unterschied?

5.1 Was beide gemeinsam haben

Bash und zsh sind beides Unix-Shells. Sie verstehen die gleichen Kernbefehle: cd, ls, mkdir, rm, cat, echo, grep, chmod, export und Hunderte mehr. Wenn Sie bash lernen, können Sie effektiv auch zsh (und umgekehrt) für den täglichen Gebrauch.

Beide sind auf Linux und macOS verfügbar. Beide sind auf Windows über Git Bash (bash) oder WSL (beides) verfügbar.

5.2 Wesentliche Unterschiede für Anfänger

5.3 Welche Shell sollten Sie verwenden?

Verwenden Sie das, was Ihr System Ihnen bietet. Die Unterschiede sind nur bei fortgeschrittener Anpassung und Skripting relevant.

• Unter Windows: Verwenden Sie Git Bash (es bietet bash). Alle Kursbeispiele funktionieren hier.
• Unter macOS: Verwenden Sie zsh (den Standard). Alle Kursbeispiele funktionieren hier ebenfalls, weil zsh bash-Befehle versteht.
• Unter Linux: Verwenden Sie bash (den Standard). Dies ist das, was die meisten Tutorials voraussetzen.

Das Fazit: Verschwenden Sie jetzt keine Zeit mit der Wahl einer Shell. Wenn Sie Befehlsbeispiele in diesem Kurs sehen, funktionieren sie in bash, zsh und Git Bash. Wenn ein Befehl PowerShell-spezifisch ist, wird dies deutlich gekennzeichnet.

6. Ihre ersten Befehle: Navigation im Dateisystem

6.1 Der Prompt: Was er bedeutet und wo Sie tippen

Wenn Sie ein Terminal öffnen, sehen Sie etwas wie:

user@computer:~/Documents$

Dies ist der Prompt. Er sagt Ihnen:

• Wer Sie sind: user (Ihr Benutzername)
• Wo Sie sind: ~/Documents (Ihr aktueller Ordner – ~ bedeutet Ihr Home-Verzeichnis)
• Die Shell ist bereit: $ (hier beginnen Sie zu tippen)

Unter Windows PowerShell sieht der Prompt anders aus, vermittelt aber die gleiche Information:

PS C:\Users\you\Documents>

Sie geben Ihren Befehl nach dem Prompt-Symbol ein ($ oder >) und drücken Enter, um ihn auszuführen.

Wichtig: Wenn Sie Befehle in Tutorials oder Dokumentationen sehen, ist das $ am Anfang der Prompt – geben Sie es nicht ein. Wenn das Tutorial zeigt:

$ git status

Tippen Sie nur git status und drücken Enter.

6.2 Grundlegende Navigationsbefehle

Dies sind die Befehle, die Sie am häufigsten verwenden werden. Lernen Sie diese und Sie können jedes System navigieren.

Beachten Sie, dass viele Befehle in bash und PowerShell gleich sind. PowerShell definiert Aliase (Abkürzungen) wie ls, cd, cat, cp, mv und rm, die auf seine eigenen Befehle verweisen. Das bedeutet, dass die grundlegenden Befehle überall funktionieren.

6.3 Dateipfade verstehen

Ein Dateipfad ist die Adresse einer Datei oder eines Ordners auf Ihrem Computer. Es gibt zwei Typen:

Absoluter Pfad – die vollständige Adresse vom Stammverzeichnis des Dateisystems:

# Linux/macOS
/home/user/Documents/project/README.md

# Windows
C:\Users\user\Documents\project\README.md

Relativer Pfad – eine Adresse relativ zu Ihrem aktuellen Standort:

# Wenn Sie in /home/user/Documents/ sind
project/README.md         # in project gehen, dann README.md
./project/README.md       # dasselbe (. bedeutet "aktuelles Verzeichnis")
../Downloads/file.zip     # eine Ebene hoch, dann in Downloads

Spezielle Pfadsymbole:

Hinweis zu Pfadtrennern: Linux und macOS verwenden Schrägstriche (/), Windows verwendet traditionell Rückwärtsschrägstriche (\). Git Bash unter Windows akzeptiert beide. Im Zweifelsfall verwenden Sie Schrägstriche – sie funktionieren fast überall.

Probieren Sie es jetzt aus:

Öffnen Sie ein Terminal und machen Sie mit:

pwd                          # Wo bin ich?
ls                           # Was ist in diesem Ordner?
mkdir terminal-practice      # Einen neuen Ordner erstellen
cd terminal-practice         # Hinein wechseln
pwd                          # Bestätigen, dass Sie drin sind
touch hello.txt              # Eine leere Datei erstellen
ls                           # Überprüfen, ob die Datei erstellt wurde
echo "Hello Terminal" > hello.txt   # Text in die Datei schreiben
cat hello.txt                # Den Dateiinhalt lesen
cd ..                        # Eine Ebene zurück nach oben
ls                           # Überprüfen, ob terminal-practice existiert

7. Programme im Terminal verwenden: Das Beispiel Git

7.1 Was passiert, wenn Sie einen Befehl eingeben

Jeder Terminal-Befehl folgt einer konsistenten Struktur. Lassen Sie uns einen echten Befehl aufschlüsseln, den Sie in Vorlesung 1 verwenden werden:

git commit -m "Add README file"
 │    │     │  └─────────────── Argument: der Wert für das -m Flag
 │    │     └────────────────── Flag: kurze Option, die das Verhalten modifiziert
 │    └──────────────────────── Unterbefehl: die spezifische auszuführende Aktion
 └───────────────────────────── Programm: das Tool, das Sie ausführen

Programm (git) – Die Software, die Sie verwenden möchten. Die Shell sucht dieses Programm in Ihrem PATH (dazu später mehr).

Unterbefehl (commit) – Was das Programm tun soll. Git hat viele Unterbefehle: clone, add, commit, push, pull, status, log und Dutzende mehr.

Flag (-m) – Eine Option, die das Verhalten des Befehls modifiziert. Das -m Flag teilt commit mit, dass das Nächste, was Sie eingeben, die Commit-Nachricht ist. Ohne -m würde git einen Texteditor öffnen, damit Sie die Nachricht schreiben können.

Argument ("Add README file") – Die Daten oder der Wert, den Sie bereitstellen. Hier ist es der eigentliche Text der Commit-Nachricht. Die Anführungszeichen sind nötig, weil die Nachricht Leerzeichen enthält.

Nicht jeder Befehl hat alle vier Teile. Einige sind einfach:

git status        # Programm + Unterbefehl (keine Flags oder Argumente)
ls                # nur ein Programm (kein Unterbefehl, keine Flags)
ls -la            # Programm + Flags (-l für Langformat, -a für alle Dateien)
cd Documents      # Programm + Argument (der Ordner, in den gewechselt wird)

7.2 Hilfe-Ausgabe lesen: –help verstehen

Jedes gut gestaltete Kommandozeilen-Tool enthält eine integrierte Dokumentation. Das --help Flag ist Ihre erste Anlaufstelle, wenn Sie nicht wissen, wie ein Befehl funktioniert.

$ git --help

Dies zeigt eine Liste aller git-Unterbefehle mit kurzen Beschreibungen. Um Hilfe zu einem bestimmten Unterbefehl zu erhalten:

$ git commit --help

Dies öffnet eine detaillierte Dokumentation. Der wichtigste Teil ist die Synopsis am Anfang:

SYNOPSIS
       git commit [-a | --all] [-m <msg>] [--amend] [<pathspec>...]

So lesen Sie diese Notation:

Also bedeutet git commit [-m <msg>]: Führen Sie git commit aus und geben Sie optional eine Nachricht mit -m gefolgt von Ihrem Nachrichtentext an.

7.3 Gemeinsame Muster bei CLI-Tools

Sobald Sie verstehen, wie ein CLI-Tool funktioniert, können Sie jedes davon verwenden. Diese Muster wiederholen sich überall:

Hilfe erhalten:

git --help            # Hilfe für das Programm
git commit --help     # Hilfe für einen bestimmten Unterbefehl
uv --help             # gleiches Muster, anderes Programm
ruff --help           # gleiches Muster, anderes Programm

Version prüfen:

git --version         # oder git -v
python --version      # oder python -V
uv --version

Kurze Flags vs. lange Flags – Die meisten Flags haben zwei Formen:

git commit -m "message"        # Kurzform: -m
git commit --message "message" # Langform: --message
# Beide tun genau dasselbe

Kurze Flags verwenden einen einzelnen Bindestrich und einen Buchstaben (-m). Lange Flags verwenden doppelte Bindestriche und ein Wort (--message). Kurze Flags sind schneller zu tippen; lange Flags sind leichter zu lesen.

Kurze Flags kombinieren:

ls -l -a          # zwei separate Flags
ls -la            # kombiniert -- gleiches Ergebnis, weniger Tippen

Probieren Sie es jetzt aus:

1. Führen Sie git --version aus – bestätigen Sie, dass Git installiert ist
2. Führen Sie git --help aus – überfliegen Sie die Liste der Unterbefehle
3. Führen Sie git commit --help aus – finden Sie die Beschreibung des -m Flags
4. Wenn Sie uv installiert haben, führen Sie uv --help aus – beachten Sie die gleichen Muster

8. PATH und Umgebungsvariablen

8.1 Das Problem: “Command Not Found”

Irgendwann werden Sie einen Befehl eingeben und etwas wie dies sehen:

$ ruff check
bash: ruff: command not found

Oder in PowerShell:

PS> ruff check
ruff: The term 'ruff' is not recognized as the name of a cmdlet, function,
script file, or operable program.

Das bedeutet nicht, dass das Programm defekt ist. Es bedeutet in der Regel, dass die Shell nicht weiß, wo das Programm zu finden ist. Hier kommt PATH ins Spiel.

8.2 Was ist der PATH?

Wenn Sie einen Befehl wie git eingeben, weiß die Shell nicht auf magische Weise, wo das git-Programm auf Ihrer Festplatte liegt. Sie muss danach suchen.

Der PATH ist eine Umgebungsvariable, die eine Liste von Ordnern enthält. Wenn Sie einen Befehl eingeben, durchsucht die Shell diese Ordner der Reihe nach, bis sie ein Programm mit diesem Namen findet.

Stellen Sie es sich wie ein Telefonbuch vor: Die Shell schlägt den Namen, den Sie eingegeben haben, in einer Liste bekannter Adressen nach.

8.3 Wie PATH auf verschiedenen Betriebssystemen funktioniert

Unter Linux, macOS und Git Bash sind PATH-Einträge durch Doppelpunkte getrennt:

$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/home/user/.local/bin

Das bedeutet, die Shell durchsucht diese Ordner der Reihe nach:

1. /usr/local/bin
2. /usr/bin
3. /bin
4. /home/user/.local/bin

Unter Windows PowerShell sind PATH-Einträge durch Semikolons getrennt:

PS> echo $env:PATH
C:\Windows\System32;C:\Program Files\Git\bin;C:\Users\you\.local\bin

Hier ist, was passiert, wenn Sie git eingeben:

8.4 Andere wichtige Umgebungsvariablen

PATH ist die wichtigste Umgebungsvariable, aber es gibt weitere:

• HOME – Ihr Home-Verzeichnis (/home/user unter Linux, /Users/user unter macOS, C:\Users\user unter Windows)
• USER – Ihr Benutzername
• LANG – Ihre Spracheinstellung (beeinflusst, wie Programme Text anzeigen)
• EDITOR – Ihr bevorzugter Texteditor (wird von git beim Schreiben von Commit-Nachrichten verwendet)

Sie können den Wert jeder Umgebungsvariable anzeigen:

# bash / zsh / Git Bash
echo $HOME
echo $USER

# PowerShell
echo $env:USERPROFILE
echo $env:USERNAME

Umgebungsvariablen sind wie globale Einstellungen für Ihre Terminal-Sitzung. Programme lesen sie, um ihr Verhalten zu konfigurieren.

8.5 “Command Not Found”-Probleme beheben

Wenn Sie einen “command not found”-Fehler erhalten, arbeiten Sie diese Checkliste durch:

Schritt 1: Ist das Programm installiert?

Versuchen Sie, es zu installieren. Wenn zum Beispiel git nicht gefunden wird, folgen Sie den Git-Installationsanweisungen in Vorlesung 1.

Schritt 2: Ist der Ordner des Programms im PATH?

Finden Sie heraus, wo das Programm installiert wurde, und prüfen Sie dann, ob dieser Ordner in Ihrem PATH ist:

# bash / Git Bash: herausfinden, wo ein Programm liegt
which git
# Ausgabe: /usr/bin/git

# PowerShell: herausfinden, wo ein Programm liegt
where.exe git
# Ausgabe: C:\Program Files\Git\cmd\git.exe

# Alternative PowerShell-native Variante:
Get-Command git

Warum where.exe und nicht einfach where? PowerShell hat ein eingebautes Alias where, das auf Where-Object verweist (ein Filter-Cmdlet) – das ist nicht dasselbe. Mit where.exe rufen Sie explizit das Windows-Systemprogramm auf, das ausführbare Dateien im PATH sucht. Alternativ ist Get-Command die PowerShell-native Methode, um herauszufinden, wo ein Programm liegt.

Wenn which, where.exe oder Get-Command ebenfalls “not found” sagt, ist der Ordner nicht in Ihrem PATH.

Schritt 3: Haben Sie das Terminal nach der Installation neu gestartet?

Viele Installer fügen ihren Ordner zum PATH hinzu, aber die Änderung wird erst in neuen Terminal-Fenstern wirksam. Schließen Sie Ihr Terminal und öffnen Sie ein neues, dann versuchen Sie es erneut.

Schritt 4 (fortgeschritten): Den Ordner manuell zum PATH hinzufügen.

Dies variiert je nach System und ist für diesen Kurs normalerweise nicht erforderlich. Wenn Sie in diese Situation geraten, bitten Sie um Hilfe.

Probieren Sie es jetzt aus:

1. Führen Sie echo $PATH (oder echo $env:PATH in PowerShell) aus – sehen Sie alle Verzeichnisse, die Ihre Shell durchsucht
2. Führen Sie which git (oder where.exe git / Get-Command git in PowerShell) aus – finden Sie genau heraus, wo git liegt
3. Zählen Sie, wie viele Verzeichnisse in Ihrem PATH sind (Tipp: zählen Sie die Trennzeichen)

9. Was ist ein Programm? Ausführbare Dateien auf verschiedenen Betriebssystemen

9.1 Programme sind nur Dateien

Ein Programm ist eine Datei auf Ihrer Festplatte, die Anweisungen enthält, die Ihr Computer ausführen kann. Das ist alles. Da steckt keine Magie dahinter.

Wenn Sie ein Programm “installieren”, kopieren Sie Dateien auf Ihre Festplatte und fügen (normalerweise) den Speicherort des Programms zu Ihrem PATH hinzu, damit die Shell es finden kann. Wenn Sie ein Programm “ausführen”, liest das Betriebssystem die Datei und folgt den darin enthaltenen Anweisungen.

9.2 Warum .exe unter Windows, aber nicht unter Linux?

Windows und Linux haben unterschiedliche Philosophien, wie ausführbare Dateien identifiziert werden:

Deshalb sehen Sie unter Windows git.exe im Dateisystem, aber unter Linux nur git. Beides ist dasselbe Programm, das dasselbe tut – das Betriebssystem identifiziert sie nur unterschiedlich.

9.3 Interpretiert vs. Kompiliert (Die 30-Sekunden-Version)

Es gibt zwei Arten von Programmen:

Kompilierte Programme (wie git oder ein C-Programm):

• Der Quellcode wird einmal von einem Compiler in Maschinencode übersetzt
• Das Ergebnis ist eine eigenständige ausführbare Datei (.exe unter Windows, keine Endung unter Linux)
• Der Computer führt sie direkt aus – keine zusätzliche Software nötig

Interpretierte Programme (wie Python-Skripte):

• Der Quellcode wird Zeile für Zeile von einem anderen Programm namens Interpreter gelesen und ausgeführt
• Die Quelldatei (.py) ist keine ausführbare Datei für sich allein
• Sie brauchen den Interpreter installiert: python my_script.py bedeutet “sage dem Python-Interpreter, diese Datei zu lesen und auszuführen”

Deshalb ist die Installation von Python notwendig, bevor Sie .py-Dateien ausführen können. Python ist der Interpreter, der Ihre Skripte liest.

Sie müssen die Details von Kompilierung vs. Interpretation für diesen Kurs nicht verstehen. Merken Sie sich einfach:

• git läuft direkt (kompiliert)
• python script.py braucht Python installiert (interpretiert)
• Beides sind gültige Wege, Programme zu erstellen

9.4 Programme vs. IDE-Erweiterungen: Warum brauche ich beides?

Beim Einrichten Ihrer Entwicklungsumgebung fällt Ihnen vielleicht etwas Verwirrendes auf: Sie installieren Python (das Programm) auf Ihrem Computer, und dann installieren Sie auch die Python-Erweiterung in VS Code. Gleicher Name, aber es sind zwei völlig verschiedene Dinge. Warum?

Das Programm (z.B. python, ruff, git) ist das eigentliche Tool, das die Arbeit erledigt. Es läuft im Terminal. Wenn Sie python script.py eingeben, liest und führt das Python-Programm Ihren Code aus. Wenn Sie ruff check eingeben, analysiert das Ruff-Programm Ihren Code auf Stilprobleme. Diese Programme existieren unabhängig von jedem Editor – sie würden genauso funktionieren, wenn Sie Notepad, Vim oder gar keinen Editor verwenden würden.

Die IDE-Erweiterung (z.B. “Python”-Erweiterung, “Ruff”-Erweiterung in VS Code) ist eine Brücke zwischen VS Code und dem Programm. Die Erweiterung enthält keinen Python-Interpreter oder Linter. Stattdessen weiß sie, wie sie mit dem installierten Programm kommuniziert und die Ergebnisse innerhalb von VS Code anzeigt.

Das Muster ist immer dasselbe:

1. Sie installieren das Programm auf Ihrem Computer (es funktioniert im Terminal)
2. Sie installieren die Erweiterung in VS Code (sie macht die Ausgabe des Programms im Editor sichtbar)
3. Die Erweiterung ruft das Programm auf – sie ersetzt es nicht

Deshalb zeigt VS Code, wenn Sie die Python-Erweiterung installieren, aber vergessen, Python selbst zu installieren, einen Fehler an, der besagt, dass kein Python-Interpreter gefunden werden kann. Die Erweiterung sucht nach dem Programm, und das Programm ist nicht vorhanden.

Stellen Sie es sich so vor: Das Programm ist der Motor. Die Erweiterung ist das Armaturenbrett. Das Armaturenbrett zeigt Ihnen Anzeigen und Warnleuchten, aber der Motor erledigt die eigentliche Arbeit. Sie brauchen beides, aber es ist nicht dasselbe.

10. Warum Automatisierung und Skripting weiterhin wichtig sind

10.1 Von einzelnen Befehlen zu Skripten

Bisher haben Sie jeweils einen Befehl eingegeben. Aber was, wenn Sie dieselbe Befehlsfolge wiederholt ausführen müssen?

Die Entwicklung von manueller zu automatisierter Arbeit sieht so aus:

1. Einzelner Befehl: mkdir project
2. Verkettete Befehle: mkdir project && cd project && git init (führt alle drei nacheinander aus; && bedeutet “und wenn das erfolgreich war, mache auch…”)
3. Shell-Skript: Befehle in einer .sh-Datei speichern und alle auf einmal ausführen
4. CI/CD-Pipeline: Befehle werden automatisch ausgeführt, wenn Sie Code auf GitHub pushen

Jede Stufe baut auf der vorherigen auf. Skripting ist die Brücke zwischen dem manuellen Eingeben von Befehlen und vollständig automatisierten Arbeitsabläufen wie GitHub Actions (die Sie in Vorlesung 3 kennenlernen werden).

10.2 Ein reales Beispiel: Ein Projekt einrichten

So sieht es aus, ein neues Projekt manuell einzurichten (die Schritte aus Vorlesung 1):

# Schritt 1: Projektordner erstellen
mkdir my-project

# Schritt 2: Hinein wechseln
cd my-project

# Schritt 3: Ein Git-Repository initialisieren
git init

# Schritt 4: Eine README-Datei erstellen
touch README.md

# Schritt 5: Inhalt hinzufügen
echo "# My Project" > README.md

# Schritt 6: Alle Dateien stagen
git add .

# Schritt 7: Den ersten Commit erstellen
git commit -m "Initial commit"

Sieben Befehle, einer nach dem anderen eingetippt. Jetzt dasselbe als Skript. Erstellen Sie eine Datei namens setup.sh:

#!/bin/bash
# setup.sh -- Ein neues Projekt erstellen und initialisieren

PROJECT_NAME="my-project"

mkdir "$PROJECT_NAME"
cd "$PROJECT_NAME"
git init
echo "# $PROJECT_NAME" > README.md
git add .
git commit -m "Initial commit"
echo "Project $PROJECT_NAME created successfully!"

Jetzt können Sie ein Projekt mit einem einzigen Befehl einrichten:

bash setup.sh

Das Skript macht genau das, was Sie manuell getan haben, aber schneller, ohne Tippfehler und wiederholbar. Wenn Sie 10 Projekte erstellen müssen, führen Sie das Skript 10 Mal aus. Wenn Sie den Einrichtungsprozess ändern müssen, bearbeiten Sie eine Datei, anstatt sich eine Befehlsfolge merken zu müssen.

10.3 Automatisierung in diesem Kurs

Skripting und Automatisierung sind nicht nur nette Zusatzfähigkeiten – sie sind zentral für modernes Software Engineering. In diesem Kurs werden Sie auf Folgendes stoßen:

• Pre-Commit-Hooks: Skripte, die Ihren Code automatisch vor jedem Commit prüfen
• GitHub Actions: Automatisierte Pipelines, die Ihren Code testen, linten und deployen, wenn Sie pushen
• Pytest: Ein Testrunner, der automatisch alle Ihre Tests findet und ausführt
• Ruff: Ein Linter, der automatisch Ihren Codestil prüft

All dies basiert auf dem gleichen Prinzip: manuelle Schritte automatisieren. Das Terminal ist der Ort, an dem diese Automatisierung lebt.

Probieren Sie es jetzt aus:

1. Erstellen Sie eine Datei namens setup.sh mit dem obigen Skript (verwenden Sie einen beliebigen Texteditor oder VS Code)
2. Öffnen Sie ein Terminal und navigieren Sie zu dem Ort, an dem Sie die Datei gespeichert haben
3. Führen Sie es aus: bash setup.sh
4. Überprüfen Sie, ob Ordner, Datei und Git-Repo erstellt wurden: ls my-project und cd my-project && git log

11. Kurzreferenz: Befehls-Spickzettel

Halten Sie diese Tabelle griffbereit, während Sie den Kurs durcharbeiten. Dies sind die Befehle, die Sie am häufigsten verwenden werden.

Tastenkombinationen, die in den meisten Terminals funktionieren:

• Pfeiltasten hoch/runter: Durch vorherige Befehle scrollen (Befehlsverlauf)
• Tab: Dateinamen und Befehle automatisch vervollständigen (Tab zweimal drücken, um alle Optionen zu sehen)
• Ctrl+C: Den aktuellen Befehl abbrechen (nützlich, wenn etwas hängt)
• Ctrl+L: Den Bildschirm leeren (dasselbe wie clear einzugeben)
• Ctrl+R: Ihren Befehlsverlauf durchsuchen (anfangen zu tippen, um zu filtern)

12. Zusammenfassung und nächste Schritte

Sie haben jetzt die Grundlage, um sicher im Terminal zu arbeiten. Hier ist, was Sie gelernt haben:

• Ein Terminal ist eine textbasierte Schnittstelle zur Kommunikation mit Ihrem Computer
• Eine Shell (bash, zsh, PowerShell) ist der Sprachinterpreter, der im Terminal läuft
• Verschiedene Betriebssysteme haben verschiedene Standard-Terminals und Shells, aber die Kernkonzepte sind dieselben
• Befehle folgen einem konsistenten Muster: Programm Unterbefehl --flag Argument
• Der PATH sagt der Shell, wo Programme zu finden sind
• Programme sind nur Dateien – die .exe-Konvention ist ein Windows-spezifisches Detail
• Automatisierung durch Skripting ist eine zentrale professionelle Fähigkeit

Wie es weitergeht:

• Bereit, Tools zu installieren? Gehen Sie zu Vorlesung 1: Git installieren und Python installieren
• VS Code einrichten? Siehe Vorlesung 1: Visual Studio Code installieren und konfigurieren
• Bereit für Git-Arbeitsabläufe? Siehe Anhang 1: Fortgeschrittene Git-Arbeitsabläufe
• Das Gesamtbild verstehen? Lesen Sie die Einführung in modernes Software Engineering