Erkennen, welche Schicht gescheitert ist

Die schnellste Frage bei der Fehlersuche lautet nicht „Was soll ich versuchen?“, sondern „Wie weit ist die Anfrage gekommen?“ Eine Fehlermeldung liefert Hinweise auf die letzte funktionierende Schicht. Wenn du sie so liest, wird aus einer roten Textwand ein Ort.

Fehler in der richtigen Reihenfolge lesen

Gehe bei den Startbeispielen dieses Kurses vier Fragen durch:

1. Befehlssuche: Hat die Shell das genannte Programm gefunden und gestartet?

2. Pfadsuche: Hat dieses Programm das übergebene Ziel gefunden?

3. Berechtigung: Hat das Betriebssystem die Aktion erlaubt?

4. Programm: Hat das Programm seine eigene Arbeit abgeschlossen?

Beginne mit dem ersten Fehler, den die Hinweise erkennen lassen. Das sind Diagnosekategorien, keine vier Phasen, die jedes Programm genau einmal durchläuft. Berechtigungen können schon den Programmstart verhindern. Ein laufendes Programm kann später beim Öffnen einer weiteren Datei scheitern. Lies die vollständige Meldung, um die fehlgeschlagene Aktion zu finden.

Jede Meldung sagt nebenbei, was bereits erfolgreich war. Ein Traceback beweist, dass die Shell Python gefunden und Python die Datei gefunden hat. Die Meldung, dass Python seine Quelldatei nicht öffnen kann, zeigt: Python ist gestartet, konnte diese Datei am versuchten Pfad aber nicht erreichen. Der Pfad kann falsch sein oder die Datei fehlen. Eine Meldung über einen nicht gefundenen Befehl belegt nicht, dass einer der beiden so weit kam.

Ein Traceback listet auf, wo während der Python-Ausführung ein Fehler auftrat. Seine letzte Zeile nennt den Fehler und eine Meldung. Ein Traceback mit PermissionError: ... Permission denied am Ende bedeutet beispielsweise: Python wurde gestartet, dann wurde eine Aktion innerhalb des Programms verweigert. Ein Ende mit FileNotFoundError verweist auf eine Datei, die das laufende Programm nicht finden konnte. Installiere Python nicht neu, nur weil eine spätere Dateioperation scheiterte.

Diagnoseübung

Setze den Arbeitsbereich von Kapitel 7 zurück und beginne in /workspace. Er enthält ein funktionierendes report.py, ein absichtlich defektes broken-report.py und ein Verzeichnis data.

Erzeuge drei der vier Fehler selbst und lies den vierten in einem Protokoll.

python ./missing-report.py
python ./broken-report.py
pythno ./report.py

python missing-report.py
python broken-report.py
pythno report.py

python missing-report.py
python broken-report.py
pythno report.py

Berechtigungsfehler brauchen eine Datei mit unpassenden Berechtigungen. Dieser Kurs bittet dich nicht, eine zu erstellen. Lies stattdessen dieses Protokoll und ordne es nur anhand des Wortlauts ein:

PS /workspace> & ./locked-tool
ResourceUnavailable: Program 'locked-tool' failed to run: Permission denied

bash: ./locked-tool: Permission denied

bash: ./locked-tool: Permission denied

Beachte, dass die Shell ./locked-tool gefunden hat und seine Ausführung versuchen konnte. Nichts war falsch geschrieben, und kein Pfad fehlte. Das Betriebssystem verweigerte die versuchte Aktion. Berechtigungseinstellungen zu untersuchen und zu ändern liegt bewusst außerhalb dieses Kurses. Der nützliche Anfängerschritt ist, die Hinweise einzuordnen, ohne Berechtigungen blind auszuweiten.

Übung: Alle vier einordnen

Nachdem du alle vier Fälle gesehen hast, schreibe auf, an welcher Schicht jeder scheiterte. Erstelle destination/diagnosis.txt mit vier Zeilen, einer pro Fall, in dieser Reihenfolge:

1. pythno report.py

2. python missing-report.py

3. ./locked-tool verweigert

4. python broken-report.py

Verwende für jeden Fall genau eine dieser Bezeichnungen: command-lookup, path-lookup, permission oder program. Der Nachweis muss genau vier nicht leere Zeilen in dieser Form enthalten:

case1=<layer>
case2=<layer>
case3=<layer>
case4=<layer>

Schreibe die erste Zeile mit Set-Content in PowerShell oder > in Bash. Hänge die übrigen drei mit Add-Content oder >> an. Lies das Ergebnis mit Get-Content oder cat und prüfe vor der Abgabe die Reihenfolge. Lass beide bereitgestellten Programme genau, wie sie sind.

Check kann die vier Bezeichnungen und die bereitgestellten Beispieldateien prüfen, dein Terminal aber nicht nachspielen. Erzeuge die Fehler und lies, wer spricht. Sonst besteht der Nachweis nur aus vier kopierten Wörtern in einem winzigen Trenchcoat.

Wenn du zwischen zwei Schichten schwankst, gehe zum Fehlertext zurück und frage, welches Programm ihn erzeugt hat. Die Antwort liegt fast immer darin, wer spricht: die Shell, der Starter, das Betriebssystem oder das Programm selbst.

Du hast jetzt einen Ablauf statt einer Liste von Vermutungen. Das letzte Kapitel beginnt mit einer vagen Meldung über etwas Fehlendes und verlangt einen Nachweis dessen, was tatsächlich falsch ist.