Ich versuche, SIGPIPE unter Linux besser zu verstehen.
Ich habe dieses Experiment ausgeführt: { ls -al /tmp/ ; echo "$?" 1>&2 ; } | head
und es gibt ein Echo aus 141, was meines Wissens nach ein Exit-Code ist, der Prozessen zugewiesen wird, die mit beendet werden. SIGPIPE Zuvor habe ich dies häufig gemacht, ohne die Nuancen von zu verstehen, SIGPIPEund normalerweise verwende ich set -eEuo pipefailes. Ich habe also versucht zu verstehen, warum mein Code nicht ständig aufgrund defekter Pipes fehlschlug ... Also habe ich dieses andere Experiment ausgeführt: ( set -o pipefail; { ls -al /tmp/ ; echo "$?" 1>&2 ; } | head; )und dieses Mal habe ich eine 0 im Echo erhalten ... wenn also pipefailaktiviert ist, bedeutet das, dass SIGPIPEunterdrückt wird? Oder verstehe ich falsch, was hier vor sich geht?
Antwort1
lskann möglicherweise die gesamte Ausgabe schreiben, bevor heades beendet wird und die Pipe unterbricht, selbst wenn die Ausgabe lslänger ist als das, was headgedruckt wird. Dies liegt daran:
headkann mehr lesen als es schließlich ausdrucken wird,- und einen Puffer für das Rohr gibt es sowieso.
SIGPIPE wird durch tatsächliches Schreiben in eine defekte Pipe ausgelöst. Wenn lses gelingt, die gesamte Ausgabe vor headdem Beenden zu schreiben, gibt es keinen Schreibvorgang, der SIGPIPE auslöst.
Oder lses gelingt ihm möglicherweise nicht, die gesamte Ausgabe zu schreiben, bevor heades beendet wird. Dann wird versucht, mehr zu schreiben und es wird SIGPIPE angezeigt.
Da lsund headparallel laufen, besteht meiner Meinung nach im Allgemeinen ein Race Condition. Es kann vorkommen, dass eine bestimmte Ausgabe von lsSIGPIPE zufällig auslöst oder nicht.
Versuchen Sie es mit yesstatt mit ls …:
{ yes ; echo "$?" 1>&2 ; } | head
oder
( set -o pipefail; { yes ; echo "$?" 1>&2 ; } | head; )
yesgeneriert eine Ausgabe, die nicht von selbst endet, sodass nach headdem Beenden immer ein Schreibvorgang erfolgt, der SIGPIPE auslöst. Jeder der oben genannten Befehle gibt Ihnen dies 141mit Sicherheit.
Das hat nichts damit zu tun pipefail.