Thomas Güttler guettliml@thomas-guettler.de (Mo 02 Sep 2019 09:15:07 CEST):
oder gleich so wie diese zwei Zeilen. Was habe ich verpasst, das Dein Script mehr macht (ausser, daß er noch Blümchen dran malt mit Datum und so und in der Ausgabe trennt nach stderr und stdout. Letzteres Feature hättest Du auf der Konsole auch nicht, wenn beide Datenströme direkt dorthin gehen.)
Zum einen will ich die Parent-Prozesse sehen. Also nicht den einen, sondern alle Elternprozesse bis ganz nach oben.
Aha, das habe ich in Deinem Py Script nicht erkannt.
Ich habe die Befürchtung, dass `exec "$@"` zwar meist funktioniert, aber es Sonderfälle gibt, bei denen es nicht klappt. Wenn zB das Argument ein Dollar, Semikolon oder Newlinezeichen enthält.
exec "$@" sollte immer funktionieren, egal, wie die Argumente aussehen, es kommt drauf an, wirklich "$@" zu schreiben, nicht $@ oder '$@' oder auch nicht "$*" bzw. andere Varianten von $*.
Aus bash(1) That is, "$@" is equivalent to "$1" "$2" ...
Wenn ich `#!/bin/sh` sehe, dann werde ich total nervös. Dass kann ja alles mögliche sein. Eine Bash, eine Dash, unter Solarix/AIX noch mal etwas anderes.
Das sollte eine Bourne-Shell sein und das, was ich da als Beispiel hatte, sollte(!) mit jeder Bourne-Shell tun, egal wie oft die wiederbelebt wurde. Das schöne an Bournce-Shell-Skripten ist ja, daß die überall gehen ;), wenn man sich diszipliniert ;)
stdout/stderr sollen ausgegeben getrennt ausgegeben werden, nicht gemeinsam. Außerdem ist die Dopplung des Stroms nötig. Also ins Logfile und auf stdout/stderr (zB mit "tee").
Das kannst Du mit dem Bash-Beipiel von mir auch haben:
- exec 3>/tmp/log + exec 3> >(tee /tmp/log)
Da geht vielleicht das hier:
#!/bin/bash exec 3>/tmp/log exec "$@" 1> >(sed -u 's/^/out: /' >&3) 2> >(sed -u 's/^/err: /' >&3)Man kann auch noch den FD 3 einsparen.
Obige Zeile verstehe ich nicht mehr. Ich schreibe seit langem keine Shell-Scripte mehr.
Ja, letztlich solltest Du es mit der Umgebung lösen, die Dir vertraut ist, aber ich wollte nur zeigen, daß heute viele alte Probleme mit Overkill gelöst werden, weil die alten Lösungen für die alten Probleme vergessen werden.
Vermutlich wird das zeilenweise gepuffert. Es gibt aber Aufrufer, die wollen zB den Fortschrittsbalken auslesen um den dann schön in einer GUI anzuzeigen. Dafür darf der Wrapper nicht puffern
Dein Wrapper puffert - wenn ich es richtig gesehen habe - noch mehr als nur zeilenweise. Oder habe ich die Stelle verpasst, wo es nach dem Lesen aus dem Select sofort wieder auf den entsprechenden Kanal rausgeschrieben wird?
„Mein“ Wrapper puffert zeilenweise, ja, weil sonst die Ausgabe mit den Präfixen durcheinander gerät.
Wenn Aufrufer sich auf den Fortschrittsbalken verlassen, sind sie arm. Das aufgerufene Programm könnte in Abwesenheit eines Terminals beschließen, gar keinen Balken zu malen.
Aber egal, wie Du es löst, Du solltest darauf verzichten, die erzeugte Ausgabe erst komplett in einem Dictionary zu speichern und anschließend auszugeben, es gibt keinen Grund dafür. Du kannst die gelesenen Daten sofort verarbeiten. Für die Ausgabe in das File könntest Du vielleicht kontrollieren, ob eine Zeile komplett ist und wenigstens so lange puffern, aber dann raus damit.
Die Annahme, daß die komplette Ausgabe des Child-Prozesses in den RAM+Swap passen wird, ist optimistisch. Assumptions are the mother of all fuck-ups.
Best regards from Dresden/Germany Viele Grüße aus Dresden Heiko Schlittermann -- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE - ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -