Linux Befehle Liste: Die 60 wichtigsten Befehle mit Beispielen (2026)

Auf unserem Ubuntu-Server findet die Shell genau 2.977 Befehle, die du eintippen könntest. Dazu kommen 61 eingebaute Befehle der Bash selbst. Niemand braucht davon auch nur ein Zehntel. Im Alltag reichen etwa sechzig, und die meisten Admins tippen dreißig davon jeden Tag. Genau dafür ist diese Linux Befehle Liste da: Sie trennt das Werkzeug, das du ständig brauchst, von den 2.900 Programmen, die nur zufällig im Pfad liegen.

Die Liste ist nach Situationen sortiert, nicht nach dem Alphabet. Erst Orientierung und Navigation, dann Dateien, dann Text durchsuchen, dann Rechte, Prozesse, Speicherplatz, Netzwerk und Pakete. Zu jedem Befehl gibt es ein Beispiel zum Kopieren. Und weil eine Liste allein wenig hilft, haben wir an den Stellen, an denen Einsteiger regelmäßig Daten verlieren, selbst nachgemessen: am 1. November 2026 auf Ubuntu 24.04.5 LTS mit Bash 5.2, GNU coreutils 9.4, findutils 4.9 und rsync 3.2.7. Sieben dieser Tests haben ein Ergebnis, das in keiner normalen Befehlsliste steht.

Wenn du noch überlegst, welches System du überhaupt nimmst, lies vorher Welches Linux für Anfänger. Fast alle Befehle hier funktionieren auf Ubuntu, Debian, Fedora und Arch gleich. Wo nicht, steht es dabei.

Wer die Grundbefehle lieber einmal vorgeführt bekommt: VoeschLabs zeigt die 20 wichtigsten Terminal-Befehle auf Deutsch (März 2026). Das Video ist zum Mitmachen gedacht, diese Liste zum Nachschlagen. Hinweis: In der Videobeschreibung stehen Affiliate-Links.

Die Linux Befehle Liste auf einen Blick

Wenn du nur die Tabelle brauchst, hier ist sie. Alles Weitere steht darunter.

Bevor es losgeht: Terminal, Shell und Hilfe

Ein Terminal ist das Fenster, in das du tippst. Die Shell ist das Programm darin, das deine Eingabe versteht und ausführt. Auf fast allen Systemen ist das die Bash, auf macOS und manchen Desktops die zsh. Für alle Befehle in dieser Liste ist der Unterschied egal.

Das Terminal öffnest du auf Ubuntu mit Strg + Alt + T. Auf einem Server bist du nach dem Login per SSH direkt in der Shell. Wie das genau funktioniert, erklären wir in Was ist SSH?.

Die drei wichtigsten Befehle sind die, mit denen du alle anderen nachschlägst:

man ls          # das vollständige Handbuch zu ls (mit q verlassen)
ls --help       # die Kurzfassung direkt im Terminal
type ll         # was steckt hinter einem Befehl?

type ist unterschätzt. Auf unserem Server antwortet type ll mit „ll is aliased to ls -alF“. ll ist also gar kein Programm, sondern eine Abkürzung, die Ubuntu in der .bashrc anlegt. Auf Fedora oder in einem Docker-Container gibt es ll oft nicht, und dann wundert man sich. Auch ls selbst ist bei uns ein Alias für ls --color=auto. Und type cd sagt „cd is a shell builtin“: cd ist gar kein Programm, sondern Teil der Bash. Deshalb gibt es keine Datei /usr/bin/cd, und deshalb hat man cd auf vielen Systemen keinen Eintrag.

Vier Tastenkürzel sparen mehr Zeit als jeder Befehl:

Strg + C ist auch die Antwort auf die häufigste Panikfrage: „Wie komme ich hier wieder raus?“ In less und man ist es die Taste q, in vim ist es Esc und dann :q!.

Navigation: pwd, ls, cd

Linux hat keine Laufwerksbuchstaben. Alles hängt unter einem einzigen Wurzelordner /. Deine Dateien liegen unter /home/deinname, Konfiguration unter /etc, Logs unter /var/log, Programme unter /usr/bin.

pwd: wo bin ich?

pwd
# /home/fabian/projekte

ls: was liegt hier?

ls              # nur Namen
ls -l           # lange Liste mit Rechten, Besitzer, Größe, Datum
ls -lah         # zusätzlich versteckte Dateien und lesbare Größen (4.0K, 12M)
ls -lt          # nach Änderungszeit sortiert, neueste zuerst
ls -lS          # nach Größe sortiert

Ein kleiner Test, der viele überrascht: Wir haben einen Ordner mit einer Datei app und einer Datei .env angelegt. ls zeigt eine Datei, ls -A zeigt zwei. Dateien, deren Name mit einem Punkt beginnt, sind unter Linux versteckt. Das betrifft genau die Dateien, die am meisten zählen: .env mit Passwörtern, .git, .ssh, .htaccess. Wer einen Ordner mit ls prüft und dann „ist leer“ sagt, liegt oft daneben. Auf Servern gehört deshalb immer -a oder -A dazu.

cd: Ordner wechseln

cd /var/log     # absoluter Pfad, beginnt mit /
cd projekte     # relativer Pfad, ab dem aktuellen Ordner
cd ..           # eine Ebene nach oben
cd ~            # ins eigene Home-Verzeichnis (cd allein tut dasselbe)
cd -            # zurück zum vorherigen Ordner

cd - ist der Befehl, den kaum ein Einsteiger kennt und den jeder Admin ständig benutzt: zwischen zwei Ordnern hin und her springen, ohne den Pfad noch einmal zu tippen.

Dateien und Ordner: anlegen, kopieren, verschieben, löschen

mkdir und touch

mkdir backup                    # einen Ordner
mkdir -p projekt/src/components # mit allen Zwischenordnern
touch notizen.txt               # leere Datei anlegen

mkdir -p meldet keinen Fehler, wenn der Ordner schon existiert. Deshalb steht es in fast jedem Skript.

cp: kopieren und die Falle beim zweiten Mal

cp datei.txt kopie.txt
cp -r ordner ziel               # Ordner rekursiv kopieren
cp -a ordner ziel               # rekursiv UND Rechte, Besitzer, Zeitstempel behalten

Zwei Dinge haben wir gemessen. Erstens: Eine Datei mit Rechten 600 und Datum 1. Januar 2020, normal mit cp kopiert, bekommt das heutige Datum. Mit cp -a bleibt der 1. Januar 2020 erhalten. Für Backups ist das der Unterschied zwischen „ich weiß, wie alt diese Datei ist“ und „alle Dateien sind von heute“. Kopiere Backups deshalb immer mit -a.

Zweitens, und das ist die eigentliche Falle: Dasselbe cp -r src ziel zweimal hintereinander ausgeführt, liefert zwei verschiedene Ergebnisse. Beim ersten Mal existiert ziel noch nicht, also wird src zu ziel und der Inhalt liegt direkt in ziel/. Beim zweiten Mal existiert ziel schon, also landet src als Unterordner darin. Unser Testordner enthielt danach den Inhalt doppelt: einmal als ziel/a/x und einmal als ziel/src/a/x. Ein Skript, das „einfach jede Nacht kopiert“, baut sich so ab der zweiten Nacht eine verschachtelte Kopie. Wer sicher gehen will, schreibt den Zielordner mit Inhalt aus (cp -a src/. ziel/) oder nimmt gleich rsync.

mv: verschieben und umbenennen ohne Rückfrage

mv alt.txt neu.txt              # umbenennen
mv datei.txt /tmp/              # verschieben
mv -i datei.txt ziel/           # vor dem Überschreiben fragen
mv -n datei.txt ziel/           # nie überschreiben

Unser Test: Datei a.txt mit Inhalt „alt“, Datei b.txt mit Inhalt „neu“, dann mv b.txt a.txt. Ergebnis: Kein Hinweis, keine Rückfrage, a.txt enthält jetzt „neu“. Der alte Inhalt ist weg, und es gibt keinen Papierkorb. Mit mv -n blieb die Zieldatei unangetastet, und coreutils 9.4 meldete „not replacing ‘c’“ mit Exit-Code 1. Für Handarbeit lohnt sich deshalb ein Alias alias mv='mv -i' in der .bashrc.

rm: löschen, endgültig

rm datei.txt
rm -i *.log                     # bei jeder Datei nachfragen
rm -r ordner                    # Ordner mit Inhalt
rm -rf ordner                   # ohne Rückfrage, ohne Fehlermeldung

rm kennt keinen Papierkorb. Was weg ist, ist weg. Und -f hat eine Nebenwirkung, die selten erwähnt wird: Es unterdrückt nicht nur Rückfragen, sondern auch die Fehlermeldung, wenn die Datei gar nicht existiert. „Gelöscht“ und „habe mich beim Namen vertippt“ sehen danach gleich aus. Wer in Skripten löscht, sollte danach prüfen, ob die Datei wirklich weg ist, statt sich auf das Schweigen zu verlassen.

Den gefährlichsten Fall zeigt der Abschnitt „Gefährliche Befehle“ weiter unten.

ln: Verknüpfungen

ln -s /var/www/seite/current aktuell   # symbolischer Link
ln -sr ordner1/ziel ordner2/link       # relativ, korrekt berechnet

Ein Klassiker aus unserem Test: ln -s ordner1/ziel ordner2/link erzeugt einen Link, der ins Leere zeigt. Der Pfad im Link wird relativ zum Ordner des Links gelesen, nicht relativ zu deinem aktuellen Ordner. cat ordner2/link meldete „No such file or directory“. Mit ln -sr rechnet ln den richtigen relativen Pfad selbst aus, und der Link funktionierte sofort. Alternativ immer absolute Pfade verwenden.

Dateien lesen und Text durchsuchen

cat, less, head, tail

cat kurz.txt                    # ganze Datei ausgeben
less lang.log                   # seitenweise, mit / suchen, q beenden
head -n 20 datei                # erste 20 Zeilen
tail -n 50 datei                # letzte 50 Zeilen
tail -n +3 datei                # ab Zeile 3 bis zum Ende
tail -F /var/log/nginx/error.log  # live mitlesen

tail -f gegen tail -F: der Test mit der Logrotation

Fast jede Anleitung sagt „tail -f zum Mitlesen“. Auf Servern ist das oft der falsche Befehl. Logs werden regelmäßig rotiert: Die alte Datei wird umbenannt (app.log → app.log.1), und eine neue app.log beginnt.

Wir haben das nachgestellt. Datei mit Zeile „l1“, beide Varianten starten, Datei umbenennen, neue Datei mit „l2“ anlegen, „l3“ anhängen. Ergebnis:

• tail -f zeigte nur l1 und danach nichts mehr. Es hängt weiter an der umbenannten alten Datei und wartet dort für immer.
• tail -F zeigte l1, l2 und l3. Es merkt, dass unter dem Namen jetzt eine neue Datei liegt, und folgt ihr.

Wenn du nachts einen Fehler beobachten willst und morgens „keine neuen Meldungen“ siehst, liegt das bei -f womöglich nur an der Rotation um Mitternacht. Nimm -F. Für Dienste mit systemd ist journalctl -u dienst -f ohnehin die bessere Wahl.

grep: Text finden

grep "error" app.log                  # Zeilen mit "error"
grep -i "error" app.log               # Groß-/Kleinschreibung egal
grep -rn "PermitRootLogin" /etc       # rekursiv, mit Dateiname und Zeilennummer
grep -v "DEBUG" app.log               # alle Zeilen OHNE DEBUG
grep -c "fehler" app.log              # Anzahl passender ZEILEN
grep -o "fehler" app.log | wc -l      # Anzahl TREFFER
grep -E "error|warn" app.log          # mehrere Muster

Der Unterschied zwischen den zwei Zählweisen ist eine typische Fehlerquelle in Auswertungen. Unsere Testdatei hatte drei Zeilen: „fehler fehler“, „ok“, „fehler“. grep -c sagt 2, weil zwei Zeilen passen. grep -o … | wc -l sagt 3, weil das Wort dreimal vorkommt. Wer „wie oft ist der Fehler aufgetreten“ wissen will und -c nimmt, zählt zu wenig, sobald eine Logzeile das Muster mehrfach enthält.

Eine Suche nach PermitRootLogin quer durch /etc dauerte bei uns übrigens 0,3 Sekunden und fand 5 Dateien. Wer viel in Code sucht, sollte sich rg (ripgrep) ansehen. Es ist schneller, ignoriert .gitignore-Dateien automatisch und war auf unserem Server schon installiert.

Pipes: Befehle verketten

Der eigentliche Trick der Kommandozeile ist das Zeichen |. Es reicht die Ausgabe eines Befehls an den nächsten weiter:

# Die 10 IP-Adressen mit den meisten Zugriffen im Nginx-Log
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

# Wie viele PHP-Dateien liegen im Projekt?
find . -name "*.php" | wc -l

sort, uniq -c, wc -l, cut, awk und sed sind die Bausteine. uniq entfernt nur aufeinanderfolgende Duplikate, deshalb steht davor fast immer sort.

Umleitung: >, >> und die leere Datei

befehl > datei.txt      # Ausgabe in Datei, ÜBERSCHREIBT
befehl >> datei.txt     # Ausgabe anhängen
befehl 2> fehler.txt    # nur Fehlermeldungen
befehl > alles.txt 2>&1 # Ausgabe und Fehler zusammen
befehl > /dev/null      # Ausgabe wegwerfen

Hier steckt eine der gemeinsten Fallen der Shell. Wir haben eine Datei mit Inhalt angelegt und dann sort datei > datei ausgeführt, also „sortiere die Datei und schreib das Ergebnis zurück“. Danach war die Datei 0 Byte groß. Der Inhalt war weg, ohne Fehlermeldung.

Der Grund: Die Shell bereitet die Umleitung vor, bevor sort überhaupt startet. > datei leert die Datei sofort. Wenn sort danach liest, findet es eine leere Datei vor. Das gilt für jeden Befehl, nicht nur für sort. Richtig ist: in eine neue Datei schreiben und dann umbenennen (sort datei > datei.neu && mv datei.neu datei), oder bei sort die eingebaute Option sort -o datei datei nutzen. Für sed gibt es sed -i.

Dateien finden: find und das Missverständnis mit -mtime

find /var/log -name "*.log"              # nach Namen
find . -type d -name node_modules        # nur Ordner
find / -size +500M 2>/dev/null           # Dateien über 500 MB
find /tmp -mtime +7                      # älter als 7 Tage (siehe unten!)
find . -name "*.tmp" -delete             # gefundene Dateien löschen
find . -name "*.sh" -exec chmod +x {} +  # Befehl auf jeden Treffer anwenden

Was -mtime +1 wirklich bedeutet

Wir haben fünf Dateien angelegt, die 12, 30, 47, 49 und 72 Stunden alt waren. Dann:

find rechnet bei -mtime in ganzen Tagen und wirft den Rest weg. Eine Datei, die 47 Stunden alt ist, gilt als „1 Tag“. +1 heißt „mehr als 1 ganzer Tag“, also tatsächlich mindestens 48 Stunden. Ein Aufräumskript mit „lösche alles älter als 7 Tage“ (-mtime +7) löscht deshalb erst ab 8 Tagen. Das ist meistens harmlos, aber bei Backup-Rotationen oder Fristen kann es entscheidend sein. Wer es genau braucht, nimmt -mmin.

-delete gehört ans Ende

Die Reihenfolge bei find ist keine Formsache. Wir haben in einem Testordner find fd -delete -name '*.log' ausgeführt, also -delete aus Versehen vor den Filter geschrieben. Ergebnis: Der komplette Ordner war weg, nicht nur die Log-Datei. find arbeitet die Ausdrücke von links nach rechts ab. -delete kommt zuerst und löscht jeden Eintrag, bevor -name überhaupt geprüft wird. Kein Fehler, keine Warnung.

Unsere Regel: Erst den find-Befehl ohne -delete laufen lassen und die Liste ansehen. Dann -delete ans Ende anhängen. Nie davor.

Rechte und Benutzer: chmod, chown, sudo

chmod 640 config.php            # Besitzer lesen/schreiben, Gruppe lesen, Rest nichts
chmod u+x skript.sh             # Besitzer darf ausführen
chmod -R g-w ordner             # Gruppe darf nirgends mehr schreiben
chown www-data:www-data datei   # Besitzer und Gruppe
sudo befehl                     # als root ausführen
sudo -i                         # root-Shell öffnen
whoami                          # wer bin ich gerade?
id                              # Benutzer, Gruppen

Die Zahlen bei chmod sind drei Ziffern für Besitzer, Gruppe und alle anderen. Lesen ist 4, Schreiben 2, Ausführen 1. 6 ist also Lesen + Schreiben, 7 ist alles. Unser Test: chmod 640 ergab -rw-r-----. Danach chmod u+x,g-r ergab -rwx------, also 700. Die Buchstabenform ändert nur, was du nennst, die Zahlenform setzt alles neu.

chmod -R 777 ist die Antwort, die man in Foren am häufigsten liest, wenn etwas „wegen Rechten“ nicht geht. In unserem kleinen Testordner hat ein einziger Befehl 53 Dateien und Ordner für jeden beschreibbar gemacht. Auf einem Webserver heißt das: Jeder Prozess, auch ein gekapertes Plugin, darf dort schreiben. Finde lieber heraus, welcher Benutzer schreiben muss, und gib genau dem die Rechte.

Die sudo-Falle mit der Umleitung

sudo echo "x" > /etc/datei        # scheitert: Permission denied
echo "x" | sudo tee /etc/datei    # funktioniert

Wir haben das als normaler Benutzer geprüft: „Permission denied“, die Datei wurde nicht angelegt. Der Grund ist derselbe wie beim sort > datei: Die Umleitung > erledigt deine eigene Shell, bevor sudo startet. sudo gilt nur für echo, nicht für das Schreiben in die Datei. tee dagegen schreibt selbst, und das läuft mit sudo-Rechten.

Prozesse und Dienste

ps aux                           # alle Prozesse
ps aux | grep "[n]ginx"          # gezielt suchen (Klammer-Trick siehe unten)
pgrep -a nginx                   # einfacher: Prozesse nach Namen
top                              # Live-Übersicht, q zum Beenden
htop                             # dasselbe, bunter und bedienbarer
kill 1234                        # Prozess höflich beenden (SIGTERM)
kill -9 1234                     # Prozess hart abschießen (SIGKILL)
pkill -f "python worker.py"      # nach Befehlszeile beenden

Der Klammer-Trick: ps aux | grep nginx findet immer auch den grep-Prozess selbst. In unserem Test zählte ps aux | grep -c sshd 4 Treffer, pgrep -c sshd nur 2. Schreibt man das Muster als [s]shd, passt es nicht mehr auf die eigene Befehlszeile. Einfacher ist pgrep.

kill gegen kill -9: der Aufräum-Test

Wir haben ein kleines Skript gestartet, das beim Beenden eine Datei „aufgeräumt“ schreibt, so wie ein Dienst beim Herunterfahren temporäre Dateien löscht oder Daten speichert. Mit kill (Signal TERM) wurde die Datei geschrieben. Mit kill -9 wurde sie nicht geschrieben, das Skript war einfach weg, und der Kindprozess lief verwaist weiter, bis wir ihn selbst beendet haben.

kill -9 ist kein „stärkeres kill“, sondern ein „kill ohne Aufräumen“. Datenbanken, Dienste mit offenen Dateien und Skripte mit Lock-Dateien hinterlassen danach Reste. Erst kill, ein paar Sekunden warten, und nur wenn sich nichts tut, -9.

systemctl und journalctl

systemctl status nginx           # läuft er? letzte Logzeilen
sudo systemctl restart nginx     # neu starten
sudo systemctl reload nginx      # Konfiguration neu laden ohne Abbruch
sudo systemctl enable --now app  # beim Booten starten und sofort starten
systemctl --failed               # alle abgestürzten Dienste
journalctl -u nginx -f           # Logs eines Dienstes live
journalctl -u nginx --since "1 hour ago"
journalctl -p err -b             # nur Fehler seit dem letzten Boot

Wie du selbst einen Dienst anlegst, zeigt systemd Service erstellen. Für wiederkehrende Aufgaben gibt es Cronjobs.

Speicherplatz und System

df -h                            # Belegung pro Dateisystem
du -sh *                         # Größe jedes Eintrags im aktuellen Ordner
du -sh /var/log                  # Größe eines Ordners
du -h --max-depth=1 / 2>/dev/null | sort -h   # größte Ordner unter /
free -h                          # Arbeitsspeicher
uptime                           # Laufzeit und Last
uname -r                         # Kernel-Version
cat /etc/os-release              # welche Distribution?
lsblk                            # Festplatten und Partitionen

Warum df und du nicht übereinstimmen

Ein Test, der zeigt, warum „Platte voll, aber ich finde nichts“ so häufig ist: Wir haben eine 200-MB-Datei erzeugt, ein Programm hat sie geöffnet, und dann haben wir sie mit rm gelöscht. du zeigte für den Ordner danach 64 KB. Der Platz war aber nicht frei, denn die Datei war nur aus dem Verzeichnis verschwunden. Solange ein Prozess sie offen hält, bleiben die 200 MB belegt. lsof +L1 hat sie sofort gefunden: Größe 209.715.200 Byte, Status „(deleted)“, gehalten von genau dem einen Prozess.

In der Praxis passiert das, wenn man eine riesige Logdatei löscht, während der Dienst noch hineinschreibt. df meldet weiter „voll“, du findet nichts. Die Lösung ist, den Dienst neu zu starten, oder die Datei nicht zu löschen, sondern zu leeren (truncate -s 0 datei).

free und der „verschwundene“ RAM

free -m zeigte auf unserem Server mit 23 GB RAM nur 1,5 GB „free“, aber 17,3 GB „available“. Das ist kein Speicherproblem. Linux benutzt freien RAM als Cache für Dateien (hier 16 GB) und gibt ihn sofort her, wenn ein Programm Speicher braucht. Die Zahl, auf die du schauen musst, ist „available“, nicht „free“. Mehr dazu im Artikel Wie viel RAM braucht ein Server?.

Unser Journal belegte übrigens 820 MB (journalctl --disk-usage), der ganze Ordner /var/log 1,4 GB. Wenn die Platte vollläuft, sind Logs und Docker-Images die ersten Kandidaten.

Netzwerk

ip a                             # Adressen aller Schnittstellen
ip r                             # Routing, Standard-Gateway
ss -tlnp                         # lauschende TCP-Ports mit Prozess
ping -c 4 getmind.io             # erreichbar?
curl -I https://getmind.io       # HTTP-Status und Header
curl -s https://api.example.com | jq .   # JSON abrufen und formatieren
wget https://example.com/datei.zip       # Datei herunterladen
dig getmind.io +short            # DNS-Auflösung
dig MX getmind.io                # Mailserver einer Domain
ssh user@server                  # Remote-Login
scp datei.txt user@server:/tmp/  # Datei kopieren

Viele Anleitungen nennen noch ifconfig und netstat. Auf unserem Server waren beide installiert, auf frischen Ubuntu- und Debian-Minimalinstallationen fehlen sie oft. Die modernen Nachfolger sind ip und ss, sie sind überall vorhanden. Wie DNS funktioniert, erklärt Was ist DNS?, und für SSH-Schlüssel gibt es SSH-Key erstellen.

rsync und der Schrägstrich

rsync -a quelle/ ziel/           # INHALT von quelle nach ziel
rsync -a quelle ziel/            # ORDNER quelle in ziel hinein
rsync -avz --delete quelle/ user@server:/backup/   # spiegeln, auch löschen
rsync -an --delete quelle/ ziel/ # Probelauf: zeigt nur, was passieren würde

Ein einziger Schrägstrich entscheidet bei rsync über das Ergebnis. Unser Test mit identischer Quelle: rsync -a src dst1/ erzeugte dst1/src/a/x, rsync -a src/ dst2/ erzeugte dst2/a/x. Einmal liegt ein Ordner mehr dazwischen. Zusammen mit --delete kann das gefährlich werden, denn --delete löscht im Ziel alles, was in der Quelle fehlt. Wer den Pfad falsch setzt, spiegelt eine leere oder falsche Quelle auf ein volles Ziel. Deshalb immer zuerst mit -n (Probelauf) testen. Unsere eigenen Deploys laufen genau so: rsync -a --delete dist/ /var/www/…, mit Schrägstrich, und nur nach erfolgreichem Build.

Archive und Pakete

tar czf backup.tgz ordner/       # packen und mit gzip komprimieren
tar xzf backup.tgz               # entpacken
tar tzf backup.tgz               # Inhalt anzeigen, ohne zu entpacken
zip -r archiv.zip ordner/        # ZIP (falls installiert)
unzip archiv.zip

# Debian / Ubuntu
sudo apt update                  # Paketlisten aktualisieren
sudo apt upgrade                 # installierte Pakete aktualisieren
sudo apt install htop            # Paket installieren
apt search ncdu                  # Paket suchen

# Fedora / RHEL
sudo dnf upgrade
sudo dnf install htop

Bei tar mit absoluten Pfaden meldete GNU tar 1.35: „Removing leading /' from member names“. Das Archiv enthielt tmp/lbl/t1statt/tmp/lbl/t1. Das ist Absicht: Beim Entpacken landet alles relativ zum aktuellen Ordner und überschreibt nicht versehentlich Systemdateien. Wer ein Archiv entpackt, sollte trotzdem vorher mit tar tzf` hineinschauen. Wie man Backups richtig aufbaut, steht in der 3-2-1-Backup-Strategie.

Nicht alles ist überall installiert. Auf unserem Server fehlten tree, ncdu, locate und fd. Vorhanden waren dagegen htop, jq, rg, dig, curl und wget. Wenn ein Befehl aus einer Anleitung „command not found“ meldet, ist er meistens nur ein apt install entfernt.

Englischsprachig, aber gut als Ergänzung: SysTelligence zeigt im September 2026 die modernen Nachfolger klassischer Befehle, also ip statt ifconfig, ss statt netstat, btop, duf und fd.

Gefährliche Befehle und wie man sie entschärft

Die meisten Datenverluste auf der Kommandozeile kommen nicht von exotischen Befehlen, sondern von harmlosen Befehlen mit einem kleinen Fehler. Diese Liste haben wir aus den Tests oben zusammengestellt.

rm -rf mit leerer Variable

rm -rf "$ORDNER/"*

Wenn $ORDNER leer ist, weil sich jemand vertippt hat oder eine Konfiguration fehlt, wird daraus rm -rf /*. Wir haben das natürlich nicht ausgeführt, sondern nur gezählt, was getroffen würde: 29 Einträge direkt unter /, also das ganze System. Die Abhilfe kostet eine Zeile:

set -u                       # Abbruch bei nicht gesetzten Variablen
rm -rf "${ORDNER:?}/"*       # Abbruch, wenn ORDNER leer ist

Mit set -u brach die Bash bei unserem Test sofort mit „unbound variable“ ab. Jedes Shell-Skript, das löscht, sollte mit set -euo pipefail beginnen.

Die übrigen Fallen im Überblick

Was all diese Fälle gemeinsam haben: Keiner davon gibt eine Fehlermeldung aus. Der Befehl läuft, meldet Erfolg, und das Problem merkt man erst später. Gegen solche stillen Fehler hilft nur Gewohnheit: Probelauf, Rückfrage-Option, und ein Backup, das man wirklich zurückspielen kann.

Wie man sich die Befehle merkt

Niemand lernt sechzig Befehle auswendig. Was funktioniert, ist eine kleine Routine:

1. Mit zehn Befehlen anfangen: pwd, ls, cd, cp, mv, rm, cat, less, grep, sudo. Damit kommt man durch die erste Woche.
2. Aliase für die eigenen Gewohnheiten in die ~/.bashrc schreiben, zum Beispiel alias ll='ls -lah' und alias mv='mv -i'. Danach source ~/.bashrc.
3. Strg + R statt Abtippen. Wer einen Befehl einmal richtig getippt hat, findet ihn so in Sekunden wieder.
4. Bei jedem neuen Befehl --help lesen, nicht nur das Beispiel aus dem Forum kopieren. Die eine Option, die man braucht, steht fast immer dort.
5. Auf einer Testumgebung üben. Eine virtuelle Maschine oder ein Docker-Container (docker run -it ubuntu bash) ist in Sekunden da und darf kaputtgehen. Wie das geht, steht in Was ist Docker?.

Wer mit Git arbeitet, findet die passenden Befehle in unserer Git Befehle Liste. Und wenn der erste eigene Server ansteht, ist Linux Server einrichten der nächste Schritt.

Fazit: Welche Linux Befehle muss man wirklich können?

Von den knapp 3.000 Befehlen auf einem normalen Linux-Server brauchst du am Anfang zehn und nach einem Jahr vielleicht sechzig. Wichtiger als die Menge ist, die Eigenheiten der häufigsten Befehle zu kennen. Unsere Tests haben gezeigt, dass die gefährlichsten Situationen keine Fehlermeldung erzeugen: mv überschreibt still, > datei leert die Datei, bevor gelesen wird, find -delete an der falschen Stelle löscht alles, tail -f verliert nach der Logrotation den Anschluss, und ein Schrägstrich bei rsync entscheidet über die Ordnerstruktur.

Wenn du dir aus dieser Linux Befehle Liste nur drei Gewohnheiten mitnimmst, dann diese: erst ohne -delete oder --delete testen, -i bei mv und rm, und set -euo pipefail in jedes Skript. Damit sind die meisten Fehler, die wir in fünfzehn Minuten Testen gefunden haben, entschärft.

Häufige Fragen zur Linux Befehle Liste

Welche Linux Befehle sollte man als Anfänger kennen?

Zehn reichen für den Anfang: pwd, ls, cd, mkdir, cp, mv, rm, cat/less, grep und sudo. Dazu man und --help zum Nachschlagen und Strg + C zum Abbrechen. Wer einen Server betreut, braucht bald auch df, du, free, systemctl, journalctl, ss und ssh.

Wie viele Linux Befehle gibt es?

Es gibt keine feste Zahl, weil jedes installierte Programm ein Befehl ist. Auf unserem Ubuntu-24.04-Server fand die Shell mit compgen -c 2.977 Befehle, dazu 61 eingebaute Bash-Befehle. In /usr/bin lagen 2.247 Programme, in /usr/sbin 479. Ein frisches Minimalsystem hat deutlich weniger.

Wie kann ich mir alle verfügbaren Befehle anzeigen lassen?

compgen -c | sort -u listet alles, was die Bash ausführen kann, einschließlich Aliase und Funktionen. Zweimal Tab auf einer leeren Zeile zeigt dasselbe interaktiv. ls /usr/bin zeigt nur die installierten Programme. Für eine Suche nach Funktion hilft apropos stichwort, zum Beispiel apropos compress.

Was ist der Unterschied zwischen Linux Befehlen und der Windows-Eingabeaufforderung?

Die Ideen sind ähnlich, die Namen nicht. ls entspricht dir, cp entspricht copy, mv entspricht move, rm entspricht del, cat entspricht type, clear entspricht cls. Linux unterscheidet Groß- und Kleinschreibung, nutzt / statt \ und hat keine Laufwerksbuchstaben. In PowerShell funktionieren einige Linux-Namen wie ls und cat als Aliase.

Wie breche ich einen Befehl ab?

Mit Strg + C. In Programmen wie less, man und top beendest du mit q. In vim drückst du Esc und tippst :q!. Wenn ein Programm gar nicht reagiert, findest du es in einem zweiten Terminal mit pgrep -a name und beendest es mit kill PID.

Was macht sudo genau?

sudo führt einen einzelnen Befehl mit Administratorrechten aus, nachdem du dein eigenes Passwort eingegeben hast. Wichtig: Es gilt nur für den Befehl selbst, nicht für Umleitungen mit >. sudo echo x > /etc/datei scheitert deshalb. Richtig ist echo x | sudo tee /etc/datei.

Was ist der gefährlichste Linux Befehl?

Bekannt ist rm -rf /, aber moderne Systeme verweigern genau diese Form ohne --no-preserve-root. Gefährlicher ist rm -rf "$VAR/"* mit leerer Variable, weil es wie ein harmloser Aufräumbefehl aussieht und trotzdem das ganze System trifft. Ähnlich gefährlich: dd auf das falsche Laufwerk und chmod -R 777 auf einem Webserver.

Wie finde ich heraus, was ein Befehl macht, bevor ich ihn ausführe?

man befehl und befehl --help erklären die Optionen. type befehl zeigt, ob es ein Alias, eine Funktion oder ein Programm ist. Für Löschbefehle gibt es oft einen Probelauf: rsync -n, find ohne -delete, apt -s. Fremde Befehle aus dem Internet erst in einer Testumgebung ausprobieren.

Warum zeigt df etwas anderes als du?

df misst, was das Dateisystem belegt meldet, du addiert die Größen der Dateien, die es in Ordnern findet. Wenn ein Prozess eine gelöschte Datei noch offen hält, zählt df sie mit und du nicht. In unserem Test waren das 200 MB, die lsof +L1 sofort angezeigt hat. Ein Neustart des Dienstes gibt den Platz frei.

Gibt es eine Linux Befehle Liste als PDF?

Eine eigene PDF-Datei bieten wir nicht an. Du kannst diese Seite aber im Browser mit Strg + P als PDF speichern, die Tabelle oben passt auf eine Seite. Ehrlich gesagt hilft ein Spickzettel weniger als --help, man und Strg + R, weil die eigene Befehlshistorie genau die Befehle enthält, die du wirklich benutzt.

Funktionieren diese Befehle auch auf dem Mac?

Größtenteils ja, macOS ist ein Unix. Viele Werkzeuge sind dort aber die BSD-Varianten mit anderen Optionen. sed -i braucht auf macOS zum Beispiel ein zusätzliches leeres Argument (sed -i '' …), find kennt manche GNU-Optionen nicht, und ip, ss, systemctl und apt gibt es gar nicht. Wer die GNU-Versionen will, installiert sie per Homebrew mit brew install coreutils findutils.