(nicht nur) mich regt seit langem auf, dass less für Aktionen der Art
bash -vx programm 2>&1 | less
unbrauchbar ist, wenn das Programm etwas länger läuft. Kaum kommt man
mal ans "Dateiende", blockiert less, bis das Programm wieder das
ausgibt (was lange dauern kann). Diese Blockade kann man zwar mit ^C
lösen, aber - haha - das hat ja gewisse Nebeneffekte, wenn less das
Ende einer Pipeline ist.
Also habe ich mir gedacht, muss ich nur dafür sorgen, dass der Rest
der Pipeline SIGINT ignoriert; schon kann ich less ordentlich
bedienen. Der gescheiterte Versuch sieht so aus:
(trap "" SIGINT;./backup_user.diff.sh 2>&1) | less
In der man page steht:
Trapped signals that are not being ignored are reset to their
original values in a child process when it is created.
Das kann man doch nur so verstehen, dass die ignorierten auch weiter
ignoriert werden. Werden sie aber nicht.
Wenn ich allerdings kein externes Programm starte, sondern eine
Ausgabe mit einer for-Schleife erzeuge, dann funktioniert es wie
erwartet (allerdings weiß ich jetzt nicht, ob das "sleep 1" von dem
^C vorzeitig beendet wurde...)
Kluge Alternativvorschläge?
Mein noch nicht getesteter Plan B sieht so aus, dass ich etwas
Shellcode zwischen das fragliche Programm und less hänge, der nach
einer Sekunde eine Leerzeile ausgibt, wenn über die Pipe nichts
kommt. Mit zsh sollte das gehen, die kennt auch non-blocking reads.
Und less könnte dann mittels --squeeze-blank-lines die meisten
Leerzeilen ausblenden.
CU
> (trap "" SIGINT;./backup_user.diff.sh 2>&1) | less
SIGPIPE.
Wenn less das 'read end' schließt, erhält der schreibende
Prozeß ein 'broken pipe' Signal.
--
printf -v email $(echo \ 155 141 162 143 145 154 142 162 165 151 \
156 163 155 141 100 171 141 150 157 157 056 143 157 155|tr \ \\\\)
# Live every life as if it were your last! #
> Am Montag, 19. Oktober 2009 05:21, Hauke Laging a écrit :
>
>> (trap "" SIGINT;./backup_user.diff.sh 2>&1) | less
>
> SIGPIPE.
> Wenn less das 'read end' schließt, erhält der schreibende
> Prozeß ein 'broken pipe' Signal.
Stimmt. Hat aber mit meinem Problem nichts zu tun. :-)
--
http://www.hauke-laging.de/ideen/