Das sind mitunter (gerade auf Blogger, GMail und Youtube) einige.
Da uzbl im Hintergrund läuft, ich es nicht beenden will, und die Meldungen von uzbl mich dabei stören, mit vim eine Konfigurationsdatei zu bearbeiten, muss uzbl jetzt sozusagen im Nachhinein zum Schweigen gebracht werden.
Das geht, wenn auch nur mit ein paar Tricks, erstaunlich gut:
#> uzbl-tabbed &
[3] 16611
#> vim config
Hier wird es jetzt nervig, uzbl stört vim mit seiner Ausgabe erheblich. Also weg mit der Ausgabe:
# CTRL - Z (Tastenkombination)
# vim ist nun angehalten im Hintergrund)
#> jobs -pl
[2]+ 16542 Angehalten vim config
[3]- 16611 Läuft uzbl-tabbed &
#> gdb -p 16611
(gdb) p dup2(open("/dev/null",0),1)
(gdb) p dup2(open("/dev/null",0),2)
(gdb) detach
(gdb) quit
#> fg
Und schon herrscht Stille :)
Was hier im Einzelnen passiert:
jobs -pl liefert mir die PID der nervigen Prozesses, danach kann per GDB an diesen Prozess "angedockt" werden. Dabei wird die Ausführung des Prozesses angehalten (der Browser bleibt also stehen, reagiert nicht mehr). Die folgenden Anweisungen zeigen (print) das Ergebnis des jeweiligen Ausdrucks dahinter.
Das ist jeweils der Aufruf einer Funktion dup2(int old, int new), welche bewirkt, dass der File Descriptor new (wenn nötig, was es in unserem Fall ist) geschlossen und anschließend zur Kopie des File Descriptors old gemacht wird.
Die Folge davon ist, dass danach in new zu schreiben effektiv das Gleiche ist, wie in old zu schreiben.
Wenn nach diesen beiden Zeilen also in File Descriptor 1 (stdout) bzw. 2 (stderr) geschrieben wird, ist dies der gleiche Vorgang wie nach /dev/null (den File Descriptor für diese "Datei" erhalten wir dank open) zu schreiben.
Die Ausgabe an stdout und stderr wird somit also nachträglich, ohne das Programm beenden zu müssen, nach /dev/null umgeleitet. Damit das nun verstummte Programm weiterläuft muss GDB mittels detach wieder "abgekoppelt" werden.
Ein quit führt zurück auf die Konsole / das Terminal und mittels fg kommt vim wieder in den Vordergrund.
Quellen:
