Thomas Güttler <[email protected]> (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 ------------ -
signature.asc
Description: PGP signature
