Ich verwende derzeit Folgendes, um alles, was zum Terminal geht, zu erfassen und in eine Protokolldatei zu schreiben
%Vor%Ich möchte jedoch nicht, dass Farbcodes / Unordnung in die Protokolldatei gelangen. also habe ich so etwas, das funktioniert.
%Vor% außer read wartet auf den Wagenrücklauf, was für einige Teile des Skripts nicht ideal ist (z. B. echo -n "..." oder printf ohne \n ).
Follow-up zu Jonathan Lefflers Antwort:
Gegeben sei das Beispielskript test.sh :
Die Ausgabe an das Terminal ist wie erwartet und es gibt keine Farb-Escape-Codes / Unordnung in der Protokolldatei wie gewünscht. Wenn ich jedoch test.log untersuche, sehe ich nicht [READ] ... (siehe Zeile 21 von test.sh ).
Die Log-Datei [meines eigentlichen Bash-Skripts] enthält die Zeile Log File: ... am Ende, auch nachdem die 4 und 5 fds geschlossen wurden. Ich war in der Lage, das Problem zu lösen, indem ich ein sleep 1 vor das zweite exec setzte - ich nehme an, dass es eine Race Condition oder fd Shenanigans gibt, die dafür verantwortlich gemacht werden können. Leider kann ich dieses Problem nicht mit test.sh reproduzieren, aber ich wäre an jeder Spekulation interessiert, die jemand haben könnte.
Ziehen Sie das Programm pee in Erwägung, das in This is diskutiert wird möglich, stdin über parallele Prozesse zu verteilen . Damit können Sie die Protokolldaten über Ihr sed-Skript senden und gleichzeitig die Farben an die tatsächliche Ausgabe senden.
Ein Hauptvorteil davon ist, dass es die Funktion " sed einmal pro Zeile der Protokollausgabe ausführen" entfernen würde. das ist wirklich teuflisch für die Leistung (in Bezug auf die Anzahl der ausgeführten Prozesse, wenn nichts anderes).
Ich weiß, dass es keine perfekte Lösung ist, aber cat -v wird nicht sichtbare Zeichen wie \x1B in sichtbare Form wie ^[[1;34m umgewandelt. Die Ausgabe wird chaotisch sein, aber es wird zumindest ASCII-Text sein.
Sie könnten versuchen, die Option -n zum Lesen zu verwenden. Es liest n Zeichen ein, anstatt auf eine neue Zeile zu warten. Du könntest es auf eins setzen. Dies würde die Anzahl der Iterationen erhöhen, in denen der Code ausgeführt wird, aber es würde nicht auf neue Zeilen warten.
Vom Mann:
-n NCHARS read returns after reading NCHARS characters rather than waiting for a complete line of input.
Hinweis: Ich habe das nicht getestet
Ich mache solche Sachen, indem ich TERM=dumb vor dem Ausführen meines Befehls setze. Das entfernte alle Kontrollzeichen außer Tab, CR und LF. Ich habe keine Ahnung, ob das für Ihre Situation funktioniert, aber es ist einen Versuch wert. Das Problem ist, dass Sie keine Farbkodierungen auf Ihrem Terminal sehen werden, da es sich um ein dummes Terminal handelt.
Sie können auch vis oder cat (insbesondere den Parameter -v ) ausprobieren und sehen, ob diese etwas für Sie tun. Sie würden sie einfach so in Ihre Pipeline einfügen:
Übrigens haben fast alle Terminalprogramme eine Option, um die Eingabe zu erfassen und sie am meisten zu bereinigen. Auf welcher Plattform arbeiten Sie und welche Art von Terminalprogramm verwenden Sie?
Könnten nicht screen -L oder die script Befehle anstelle dieser Exec-Schleife praktikable Optionen sein?