Ich habe im Gnome-Terminal einen Befehl ausgeführt, der mehr Ausgabe auf das Terminal gedruckt hat als erwartet. Ich möchte die gesamte Ausgabe lesen, aber das Scrollen im Terminal stoppt, bevor es den Anfang erreicht.
Ich verstehe, dass ich die Terminalprofileinstellungen ändern kann, um unbegrenztes Scrollen zu ermöglichen oder die Ausgabe in eine Datei umzuleiten usw. Alle diese gängigen Lösungen gelten fürZukunftAusgabe jedoch.
Wie kann ich die vollständige Terminalausgabe eines bereits ausgeführten Befehls anzeigen?
Edit: Alles klar, das geht nicht. Danke an alle!
Antwort1
Meiner Erfahrung nach ist der Konsens in den Kommentaren richtig – sobald der Puffer des Terminals überschritten wurde, sind die Daten verloren (oder so gut wie – sie könnten sich möglicherweise in einem Speicher befinden, der noch nicht überschrieben wurde) – und aus diesem Grund können Sie die Puffergröße nicht nachträglich erhöhen.
Diese Antwort ist irgendwo zwischen einem Kommentar, einer Antwort und vielleicht einem Overkill für Ihre Situation. Es ist eher ein vorgeschlagener Ansatz, der Ihre Situation ansprechen könnte – insbesondere das Problem, nicht zu wissen, dass Sie das Protokoll benötigen, bis es zu spät ist (nicht-kausale Probleme sind schwierig), aber es ist keine direkte Antwort auf Ihre Frage.
Auf jeden Fall war es zu lang für einen Kommentar. Ich liste nicht den gesamten Code auf, der zur Implementierung dieses Ansatzes erforderlich ist, hauptsächlich, weil eine Reihe von Implementierungsentscheidungen getroffen werden müssen. Wenn Sie detailliertere Informationen benötigen, stelle ich sie Ihnen gerne zur Verfügung.
Scriptist alles andere als angenehm im Umgang
Zunächst einmal scriptwurde das Dienstprogramm als „Überbrückungsmaßnahme“ vorgeschlagen, um Datenverlust zu verhindern, ohne die Puffergröße zu erhöhen (was Sicherheitsauswirkungen hat, wenn sie auf unbegrenzt eingestellt ist). Wenn es jemals ein Dienstprogramm gab, das etwas Pflege brauchte, dann scriptist es dieses. Andererseits wurde es vom Kernel-Team entwickelt. Lesen Sie das, wie Sie wollen.
Ich finde script, dass es oft mehr Mühe macht als es wert ist (Nachbearbeitung, um es halbwegs menschenlesbar zu machen usw.) und habe stattdessen begonnen, eine vereinfachte Methode zum Protokollieren von stdout, stdin und/oder stderr zu verwenden. In gewisser Weise ist dies eine Neuerstellung des Skripts, aber mit voller Kontrolle, anstatt den fest codierten scriptProtokollierungseinstellungen ausgeliefert zu sein.
Dieser Ansatz könnte relativ nahtlos in Ihre Shell-Sitzungen integriert werden, und in den seltenen Fällen, in denen der Terminalpuffer übergelaufen ist, haben Sie eine temporäre Datei mit diesem Inhalt. Um die Protokollierung „sauber“ zu halten, müssen Sie einige organisatorische Schritte durchführen. Darüber hinaus bestehen standardmäßig dieselben Sicherheitsprobleme (Protokollierung aller Terminalausgaben); es gibt jedoch eine einfache Methode zum Verschlüsseln der Protokolle.
Es gibt drei grundlegende Schritte:
- Konfigurieren Sie die Umleitung so, dass Sie stdout (und stderr, falls gewünscht) in eine Datei und zum Terminal aufteilen. Ich habe dieses Beispiel einfach gehalten und leite stdin oder stderr nicht in die Datei um. Wenn Sie jedoch das Beispiel der stdout-Umleitung verstehen, ist der Rest trivial.
- Konfigurieren Sie .bashrc so, dass diese Protokollierung immer beginnt, wenn eine Shell geöffnet wird.
- Wenn eine bestimmte Shell geschlossen wird, verwenden Sie das integrierte Bash-Programm,
TRAPum Benutzercode aufzurufen, der die Sitzungsprotokollierung beendet (Sie können die Datei löschen, archivieren usw.).
Mit diesem Ansatz verfügen Sie effektiv über ein unsichtbares Sicherheitsnetz, das Ihnen den gesamten Verlauf einer bestimmten Shell-Sitzung anzeigt (basierend auf Ihrer Umleitung – auch hier zeige ich der Vereinfachung halber nur stdout). Wenn Sie es nicht benötigen, sollten Sie nicht einmal wissen, dass es da ist.
Einzelheiten
1. Umleitung konfigurieren
Der folgende Codeausschnitt erstellt einen Dateideskriptor 3, der auf eine Protokolldatei verweist. stdout wird auf 3 umgeleitet, und mithilfe von teeteilen wir diesen Stream dann wieder in das Terminal auf (entspricht stdout). Sie können stderr ganz einfach zum selben Befehl/der selben Protokolldatei hinzufügen, es in eine andere Datei umleiten oder es so lassen, wie es ist (nicht protokolliert).
logFile=$(mktemp -u)
exec 3>&1 1> >(tee $logFile >&3)
Sie werden feststellen, dass diese Protokolldatei weitaus übersichtlicher ist als die vom Skript generierte Datei. Sie speichert keine Backspaces, Zeilenvorschübe und andere Sonderzeichen, die häufig unerwünscht sind.
Beachten Sie, dass Sie die Protokolldatei ganz einfach verschlüsseln können, indem Sie nach dem Tee-Befehl eine zusätzliche Pipe-Phase hinzufügen.openssl.
2. Automatisieren Sie die Protokollgenerierung
Fügen Sie in .bashrc den gleichen Code wie oben hinzu. Jedes Mal, wenn eine neue Shell erstellt wird, wird eine für diese Sitzung spezifische Protokolldatei erstellt.
export logFile=$(mktemp -u)
exec 3>&1 1> >(tee $logFile >&3)
echo "Current session is being logged in $logFile"
3. Protokollierung automatisch beenden, wenn Shell geschlossen wird
Wenn Sie möchten, dass die Protokolldatei nach Beendigung der Sitzung gelöscht wird, können Sie trapbeispielsweise die in Bash integrierte Funktion zum Erkennen der Sitzungsbeendigung verwenden und eine Funktion zum Adressieren der Protokolldatei aufrufen (auch in .bashrc).
trap closeLog EXIT
closeLog () {
rm -f "$logFile" >/dev/null 2>&1
}
Die Bereinigung der Sitzungsprotokollierung kann auf verschiedene Arten erfolgen. Dieser Ansatz wird aufgerufen, wenn die Shell geschlossen wird, indem das „Exit“-Signal abgefangen wird. An diesem Punkt können Sie die Protokolldatei löschen, verschieben/umbenennen oder auf andere Weise bereinigen. Sie können die Protokolldateien auch von einem Cron-Job statt über ein TRAP bereinigen lassen (wenn dieser Ansatz verwendet wird, würde ich eine regelmäßige Bereinigungsaufgabe vorschlagen, wenn Sie nicht bereits eine für das Verzeichnis /tmp konfiguriert haben; wenn die Bash-Shell abstürzt, wird die EXIT-Trap nicht ausgelöst).
Hinweis zum Umgang mit Unterschalen
Bei Subshells ergibt sich eine interessante Situation. Wenn eine neue interaktive Shell über einer bestehenden geöffnet wird, wird ein neues Protokoll erstellt und alles sollte einwandfrei funktionieren. Wenn diese Shell beendet wird (und zur übergeordneten Shell zurückkehrt), wird die Protokollierung in dieser Datei fortgesetzt. Wenn Sie dies sauberer angehen möchten – vielleicht sogar ein gemeinsames Protokoll für Subshells (interaktive oder andere) führen möchten – müssen Sie (in .bashrc) feststellen, dass Sie sich in einer verschachtelten Subshell befinden, und zur Protokolldatei der übergeordneten Shell umleiten, anstatt eine neue zu erstellen. Sie müssen auch überprüfen, ob Sie sich in einer Subshell befinden, damit Ihr „Trap“-Aufruf die Protokolldatei der übergeordneten Shell beim Beenden nicht löscht. Sie können die Ebene der verschachtelten Shell aus der Bash-Umgebungsvariable SHLVL abrufen, die die „Tiefe“ Ihres Shell-Stapels speichert.
Hinweis zum „Sauberhalten“ Ihres Protokolls:
Wenn Sie stdin zur Protokolldatei umleiten, erhalten Sie viele der gleichen unerwünschten Artefakte, die das Skript-Dienstprogramm generiert. Dies kann durch Hinzufügen einer Filterstufe (z. B. sed/grep) zwischen der Umleitung und der Datei behoben werden. Erstellen Sie einfach einen regulären Ausdruck, der alles entfernt, was nicht protokolliert werden soll. Um dies vollständig zu bereinigen, wäre eine ziemlich gründliche Verarbeitung erforderlich (möglicherweise Puffern jeder neuen Zeile vor dem Schreiben in die Datei, Bereinigen und dann Schreiben). Andernfalls ist es schwierig zu erkennen, wann ein Backspace „Müll“ ist oder beabsichtigt ist.
Antwort2
Der traditionelle Weg war, PuTTY zu verwenden und Tausende von Zeilen beizubehalten. Es gibt auch Screen, da nicht viele Linux- (oder lokale) Benutzer PuTTY verwenden.
Jetzt, da Windows über SSH in der Befehlszeile verfügt, gerät es in Vergessenheit.