Teil 13

Eine persönliche Bibliothek aufbauen: nützliche Arbeit in übertragbares Handwerk verwandeln

An diesem Punkt ist das Terminal keine Befehlsliste mehr. Es wird zu einer Sammlung vertrauenswürdiger Methoden: so untersuche ich dieses Problem, so verwandle ich diese Dateien, so packe ich dieses Projekt, so prüfe ich ein Release, so baue ich die Umgebung neu auf.

Methoden in einer Bibliothek statt im Gedächtnis speichern

Ordner nach Zweck anlegen — checks, deploy, media, migration, diagnostics — und für jede bewährte Routine ein kurzes Skript oder eine Notiz aufheben. Der Ordnername sollte erklären, wann Sie in sechs Monaten danach greifen würden.

Schon ein privater Ordner, den Sie zwischen Projekten übernehmen, ist eine portable persönliche Umgebung. Er bewahrt viele kleine Entscheidungen, die sonst jedes Mal neu erarbeitet werden müssten.

cd lil-playground

md library

md library/checks

md library/deploy

md library/media

Kleine Rezepte bevorzugen, die sich zusammensetzen lassen

Eine gute Routine beantwortet eine Frage oder führt eine begrenzte Transformation aus. hosting-baseline.lil, package-project.lil und network-check.lil sind leichter zu vertrauen als ein Riesenskript, das zugleich Konfiguration editiert, Dateien hochlädt, Rechte ändert und eine Datenbank berührt.

Komposition hält Risiko sichtbar. Eine lineare #lil-Datei ruft normale Befehle auf; ein run-Ablauf kann bei nötigen Entscheidungen untergeordnete Abläufe aufrufen. Namen, erwartete Eingaben und Ausgaben klar halten.

Die Änderung festhalten, nicht nur die fertige Datei

diff macht aus zwei Textzuständen eine überprüfbare Änderung und kann einen Patch speichern. Das ist oft informativer als eine zweite Kopie namens final-final-2.txt, weil die Änderung selbst sichtbar wird.

Bei Release-Artefakten hash ergänzen. Ein Patch erklärt, was sich änderte; ein Digest sagt später, ob die Bytes noch identisch sind. Beides ersetzt kein Backup, erleichtert Übergabe und Verifikation aber erheblich.

echo "status=review" > library/routine-v1.txt -r

echo "status=done" > library/routine-v2.txt -r

diff library/routine-v1.txt library/routine-v2.txt

diff library/routine-v1.txt library/routine-v2.txt -o library/routine.patch

Kleine exakte Hilfswerkzeuge vermeiden unnötigen Einmal-Code

rand erzeugt sichere Ganzzahlen, Tokens und UUIDs; math erledigt validierte Berechnungen und Konvertierungen. Praktisch, wenn ein Ablauf einen exakten Wert braucht und ein temporäres PHP-Skript mehr Oberfläche als Nutzen erzeugen würde.

Ein kryptografisch sicherer Zufallswert ist noch kein Secret-Management-System, und ein Rechner ist keine Business-Rule-Engine. Kleine Werkzeuge für kleine Aufgaben nutzen und wichtige Regeln explizit im Ablauf lassen.

rand -uuid

rand 1 100

math clamp 105 0 100

math round 82.456 1

Das Werkzeug pflegen, bevor ein Notfall Wartung dringend macht

Gelegentlich core, doctor -q und upgrade -c ausführen, wenn alles gesund ist. So lernen Sie, wie „normal“ aussieht, und entdecken Updates oder fehlende Abhängigkeiten vor einem Produktionsvorfall.

Wartung ist am besten langweilig. Vertrauen Sie dem Software-Repository bewusst, prüfen Sie Änderungen, bewahren Sie Sicherungen auf und dokumentieren Sie die wenigen lokalen Entscheidungen, die diesen Host von einem anderen unterscheiden.

core

doctor -q

upgrade -c

Eine Ebene zurücksetzen, ohne die ganze Umgebung zu verbrennen

clear setzt nur die Anzeige zurück. Module lassen sich einzeln deinstallieren. Das optionale Interface kann separat zurückgesetzt werden. Die Extension-Schicht kann verschwinden, während Core bleibt. Vollständiges kill existiert, ist aber die letzte Grenze, kein Troubleshooting-Reflex.

Dieses Schichtenmodell ist allgemein eine gute Terminalgewohnheit: den kleinsten tatsächlich defekten Zustand identifizieren und nur ihn zurücksetzen. Zerstörung ersetzt selten Diagnose.

clear

Mit einem Ablauf enden, dessen Ergebnis beweisbar ist

Das finale Beispiel prüft den Workspace, erstellt ein Archiv, testet das TAR, inspiziert das Artefakt und berechnet einen Digest. Jeder Schritt bestätigt eine Vorbedingung oder liefert Beleg für den nächsten.

Zuerst mit -n, danach mit -v ausführen. Root- und Archivnamen erst ändern, wenn die Ausgabe verstanden ist. Ziel ist nicht dieses eine Archiv, sondern die Gewohnheit, Abläufe zu bauen, die sich selbst erklären.

run library/release-check.lil -n

run library/release-check.lil -v

Die eigentliche Fähigkeit ist die Methode, nicht das Befehlsvokabular

Linux, macOS, Windows und Hosting-Laufzeitumgebungen sind nicht gleich, und lil-terminal behauptet das auch nicht. Übertragbar ist die Kultur: aktuellen Zustand prüfen, begrenzte Änderung vornehmen, Ergebnis verifizieren und den wiederholbaren Teil speichern.

Wenn das natürlich wird, ist ein neues Terminal keine Wand aus unbekannter Syntax mehr. Sie haben Fragen, Belege und Routinen, die angepasst werden können. Genau darum geht es in dieser Einführung: nicht Lernen abzuschließen, sondern die Kommandozeile zu einem Ort zu machen, an dem Sie arbeiten können.

Als Skript aufbewahren

Speichern Sie den finalen Ablauf als library/release-check.lil. Er kennt Ihr Geschäftsprojekt nicht; er zeigt ein übertragbares Prüfmuster für eine Veröffentlichung: Arbeitsbereich prüfen, Archiv erstellen, testen, inspizieren und einen Digest festhalten.

set root lil-playground
set archive lil-playground-checkpoint.tar

if dir "$root"
    dir "$root" 1 -G
    tar "$root" "$archive" -f
    tar "$archive" -t
    stat "$archive"
    hash "$archive"
else
    stop "Workspace is missing"
end