Am Ende dieser Sitzung werden Sie:

1. Verstehen, was ein Terminal ist und warum Entwickler es nutzen
2. Kennen, den Unterschied zwischen Terminal, Shell und Betriebssystem
3. Navigieren können im Dateisystem mit Textbefehlen
4. Lesen können von Befehlssyntax wie git commit -m "message"
5. Verstehen, was PATH ist und "command not found"-Fehler beheben
6. Erkennen, warum Automatisierung durch Scripting eine Kernkompetenz ist

Alles in diesem Kurs läuft über das Terminal:

• Installation von Git, Python und Werkzeugen
• Repositories klonen und Code verwalten
• Tests, Linter und Formatter ausführen
• CI/CD-Pipelines und Deployment

Wenn "öffne ein Terminal und tippe diesen Befehl" einschüchternd klingt -- diese Sitzung ist für dich.

Viele professionelle Entwickler haben genau dort angefangen, wo du jetzt bist.

Stell es dir wie einen Chat vor:

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

Du:        "Erstelle einen neuen Ordner namens 'project'"
Computer:  (Stille bedeutet Erfolg)

In der Praxis:

$ ls
document.txt  photo.jpg  notes.md

$ mkdir project

Das $ ist der Prompt -- es bedeutet "bereit für deinen nächsten Befehl." Nicht eintippen!

Hast du schon einmal ein Terminal benutzt?

• A) Noch nie -- das ist alles neu für mich
• B) Ein paar Mal, aber ich fühle mich nicht sicher
• C) Ich benutze es gelegentlich
• D) Ich bin bereits sicher im Umgang damit

Keine falsche Antwort! Diese Sitzung bringt alle auf den gleichen Stand.

1960er-70er: Ein "Terminal" war ein physisches Gerät -- Tastatur + Bildschirm an einem Großrechner

Heute: Terminal-Emulatoren -- Software, die diese Textkonversation simuliert

Immer noch das Fundament moderner IT:

• Server, die Websites betreiben
• Cloud-Infrastruktur
• Automatisierte Test-Pipelines
• Deployment-Systeme

Jeder professionelle Entwickler, Sysadmin und DevOps-Ingenieur nutzt das Terminal täglich.

Wichtige Erkenntnis: Die GUI-Buttons in VS Code sind Wrapper um Terminal-Befehle. Terminal verstehen = die gesamte Pipeline verstehen.

Einen Projektordner mit README erstellen:

GUI: Explorer öffnen → Navigieren → Rechtsklick → Neuer Ordner → Benennen → Öffnen → Rechtsklick → Neue Datei → Benennen → 7 Schritte

Terminal:

mkdir project && cd project && touch README.md

1 Zeile. Fertig.

Und du kannst diese Zeile speichern und für immer wiederverwenden.

Tools wie GitHub Copilot CLI können natürliche Sprache in Terminal-Befehle übersetzen.

Warum also Terminal-Befehle lernen?

Aus dem gleichen Grund, warum man Mathematik lernt, obwohl es Taschenrechner gibt:

• Du musst verstehen, was die KI vorschlägt, bevor du es ausführst
• Du musst überprüfen und debuggen, wenn etwas schiefgeht
• Du brauchst mentale Modelle, um gute Fragen zu stellen

KI verstärkt Verständnis -- sie ersetzt es nicht.

Sogar das Prompt-Symbol unterscheidet sich: >, %, $

Alle haben den gleichen Zweck: "Ich bin bereit für deinen nächsten Befehl."

• Terminal = das Fenster (Anzeige, Farben, Schriften, Kopieren/Einfügen)
• Shell = die Sprache, die darin läuft (interpretiert deine Befehle)

Analogie:

Das Terminal ist das Telefon. Die Shell ist die Sprache, die du am Telefon sprichst.

Gleiches Telefon, verschiedene Sprachen. Gleiches Terminal-Fenster, verschiedene Shells.

Warum verwirrend? "PowerShell" ist sowohl eine Shell ALS AUCH eine Terminal-App. "Git Bash" ist ein Terminal, das bash ausführt. Die Namen sind inkonsistent -- das Konzept zählt.

Was meint jemand, wenn er sagt "öffne bash"?

• A) Eine Terminal-Anwendung öffnen, die die bash-Shell ausführt
• B) Ein neues Programm namens "bash" installieren
• C) Einen Webbrowser öffnen
• D) Die Windows-Eingabeaufforderung öffnen

Denke an den Unterschied zwischen Terminal und Shell!

Unsere Empfehlung: Verwende Git Bash oder das VS Code Terminal mit Git Bash. So funktionieren alle Kursbeispiele auf jedem Betriebssystem.

Öffnen: `Ctrl+`` (Backtick) oder Ansicht → Terminal

Das VS Code Terminal ist eine Terminal-Anwendung mit deiner Wahl der Shell darin.

Klicke auf den Dropdown (▾) neben + um verfügbare Shells zu sehen:

• PowerShell (Standard unter Windows)
• Git Bash
• Eingabeaufforderung
• JavaScript Debug Terminal

Git Bash als Standard setzen:
Ctrl+Shift+P → "Terminal: Select Default Profile" → Git Bash

Beide verstehen die gleichen Kernbefehle: cd, ls, mkdir, rm, cat, echo, grep...

Fazit: Benutze, was dein System mitbringt. Nicht zu viel nachdenken.

user@computer:~/Documents$

Das sagt dir:

• Wer du bist: user
• Wo du bist: ~/Documents (~ = Home-Ordner)
• Bereit für Eingabe: $

Unter Windows PowerShell:

PS C:\Users\du\Documents>

Wenn Tutorials $ am Anfang zeigen -- nicht eintippen!

$ git status    # ← du tippst nur: git status

Diese funktionieren in bash, zsh, Git Bash und PowerShell (über Aliase).

Warnung: rm hat keinen Papierkorb. Gelöschte Dateien sind weg. Vorsicht!

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

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

project/README.md
./project/README.md
../Downloads/file.zip

Spezielle Symbole: . = aktuelles Verz., .. = übergeordnetes Verz., ~ = Home, / = Root

Tipp: Git Bash unter Windows akzeptiert Schrägstriche / -- benutze sie!

Mach mit in deinem Terminal:

pwd                          # Wo bin ich?
ls                           # Was ist in diesem Ordner?
mkdir terminal-practice      # Neuen Ordner erstellen
cd terminal-practice         # Hineingehen
pwd                          # Standort bestätigen
touch hello.txt              # Leere Datei erstellen
echo "Hello Terminal" > hello.txt   # Text hineinschreiben
cat hello.txt                # Datei lesen
cd ..                        # Eine Ebene zurück

Nimm dir 3 Minuten. Probiere jeden Befehl. Frag, wenn etwas unklar ist!

git commit -m "Add README file"
 │    │     │  └─── Argument: der Wert für -m
 │    │     └────── Flag: ändert das Verhalten
 │    └──────────── Unterbefehl: die Aktion
 └───────────────── Programm: das Werkzeug

Nicht jeder Befehl hat alle Teile:

git status        # Programm + Unterbefehl
ls                # nur ein Programm
ls -la            # Programm + Flags
cd Documents      # Programm + Argument

Jedes gute CLI-Tool hat eingebaute Dokumentation:

git --help              # alle Unterbefehle auflisten
git commit --help       # detaillierte Hilfe für commit

So liest du die Synopsis:

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

Diese Muster wiederholen sich überall:

# Hilfe bekommen
git --help          python --help          ruff --help

# Version prüfen
git --version       python --version       uv --version

Kurze vs. lange Flags:

git commit -m "message"        # kurz: -m
git commit --message "message" # lang: --message

Kurze Flags kombinieren:

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

Identifiziere die Teile:

git clone --depth 1 https://github.com/user/repo.git

Besprich mit deinem Nachbarn:

1. Was ist das Programm?
2. Was ist der Unterbefehl?
3. Was ist das Flag und was könnte es bewirken?
4. Was ist das Argument?

Nimm dir 2 Minuten, dann besprechen wir es.

Irgendwann wirst du das sehen:

$ ruff check
bash: ruff: command not found

Oder in PowerShell:

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 kaputt ist.

Meist weiß die Shell einfach nicht, wo sie das Programm finden kann.

PATH = eine Liste von Ordnern, die die Shell durchsucht, wenn du einen Befehl eingibst

Stell es dir wie ein Telefonbuch vor: die Shell schlägt den Befehlsnamen in einer Liste bekannter Adressen nach.

# bash / Git Bash (durch Doppelpunkte getrennt)
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/home/user/.local/bin

# PowerShell (durch Semikolons getrennt)
PS> echo $env:PATH
C:\Windows\System32;C:\Program Files\Git\bin

Wenn du git tippst, prüft die Shell jeden Ordner der Reihe nach, bis sie git findet.

Schritt 1: Ist das Programm installiert? Wenn nicht, installiere es.

Schritt 2: Ist sein Ordner im PATH?

which git            # bash / Git Bash
where.exe git        # PowerShell (nicht nur "where"!)
Get-Command git      # PowerShell-native Alternative

Hinweis: where allein in PowerShell ist ein Alias für Where-Object -- nicht das Richtige!

Schritt 3: Hast du das Terminal nach der Installation neu gestartet?

Viele Installer ändern den PATH, aber Änderungen gelten nur für neue Terminal-Fenster.

Schritt 4 (fortgeschritten): Ordner manuell zum PATH hinzufügen. (Frag um Hilfe.)

In 90% der Fälle löst Schritt 3 das Problem!

PATH ist die wichtigste, aber es gibt weitere:

echo $HOME       # bash / Git Bash
echo $env:USERPROFILE   # PowerShell

Umgebungsvariablen = globale Einstellungen für deine Terminal-Sitzung.

Probiere diese Befehle in deinem Terminal:

# Deinen PATH anzeigen
echo $PATH

# Herausfinden, wo git liegt
which git

# Verzeichnisse in deinem PATH zählen
# (Tipp: zähle die Doppelpunkte oder Semikolons)

Fragen zur Diskussion:

• Wie viele Verzeichnisse durchsucht deine Shell?
• Wo ist git auf deinem Rechner installiert?
• Was passiert, wenn zwei Ordner im PATH beide git enthalten?

Ein Programm ist eine Datei mit Anweisungen, die dein Computer ausführen kann. Das ist alles.

Ein Programm "installieren" = Dateien auf die Festplatte kopieren + den Speicherort zum PATH hinzufügen

Ein Programm "ausführen" = das Betriebssystem liest die Datei und folgt den Anweisungen

Deshalb muss Python installiert sein, bevor du .py-Dateien ausführen kannst.

Python ist der Interpreter, der deine Skripte liest.

Warum Python UND die Python VS Code Extension installieren?

Die Extension ruft das Programm auf -- sie ersetzt es nicht.

Das Programm ist der Motor. Die Extension ist das Armaturenbrett.

Die Progression:

Einzelbefehl → Verkettete Befehle → Shell-Skript → CI/CD-Pipeline

# 1. Einzeln
mkdir project

# 2. Verkettet (&&  bedeutet "wenn erfolgreich, dann auch...")
mkdir project && cd project && git init

# 3. Skript (in setup.sh speichern, ausführen mit: bash setup.sh)

# 4. CI/CD (läuft automatisch wenn du Code pushst)

Jede Stufe baut auf der vorherigen auf. Das Terminal ist der Ort der Automatisierung.

setup.sh -- Projekt erstellen und initialisieren:

#!/bin/bash
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!"

Ausführen: bash setup.sh

Schneller, keine Tippfehler, wiederholbar. 10 Projekte nötig? 10 Mal ausführen.

All das wirst du kennenlernen -- alles basiert auf Terminal-Automatisierung:

• Pre-commit Hooks -- Skripte, die Code vor jedem Commit prüfen
• GitHub Actions -- automatisierte Pipelines beim Push
• Pytest -- findet und führt alle Tests automatisch aus
• Ruff -- prüft deinen Code-Stil automatisch

Das Muster ist immer gleich: manuelle Schritte automatisieren.

1. Erstelle eine Datei namens setup.sh (mit VS Code oder einem Editor)
2. Füge das Skript von der vorherigen Folie ein
3. Öffne ein Terminal und navigiere zur Datei
4. Führe es aus:

bash setup.sh

5. Überprüfe:

ls my-project
cd my-project && git log

Nimm dir 5 Minuten. Heb die Hand, wenn du den Commit siehst!

Tab-Vervollständigung ist dein bester Freund -- anfangen zu tippen und Tab drücken!

Ctrl+C ist deine Notbremse -- benutze es, wenn etwas hängt.

1. Ein Terminal ist eine Textschnittstelle; eine Shell ist die Sprache darin
2. Verschiedene Betriebssysteme = verschiedene Standards, aber Kernbefehle sind gleich
3. Befehle folgen: Programm Unterbefehl --Flag Argument
4. PATH sagt der Shell, wo Programme zu finden sind
5. Programme sind nur Dateien -- Erweiterungen sind nur Konventionen
6. Automatisierung durch Scripting ist eine professionelle Kernkompetenz

Du hast jetzt das Fundament, um sicher im Terminal zu arbeiten!

Bereit, diese Fähigkeiten einzusetzen? Gehe zu:

• Tools installieren: Vorlesung 1: Git installieren
• VS Code einrichten: Vorlesung 1: VS Code Setup
• Git-Workflows: Anhang 1: Fortgeschrittenes Git

Vollständige Vorlesungsreferenz: Anhang 0 Teil 1: Terminal- und CLI-Grundlagen