Re: Wrapper für /usr/bin/dpkg
Hallo Thomas, On Fri, Sep 06, 2019 at 15:31:27 +0200, Thomas Güttler wrote: > Linux und Shell sind zwei getrennte Dinge. Dank systemd ist es gar > nicht so unvorstellbar einen Server zu betreiben auf der gar keine Shell > installiert ist. Fände ich cool. Und irgendwann loest systemd dann auch den Kernel ab. Nein danke. Ein Linux-System ohne Shell ist zwar denkbar, aber sobald auch nur ein Binary (oder eine Library) die libc-Funktionen popen() oder system() verwendet, ist zumindest /bin/sh wieder notwendig. Und die Vorstellung, etwa Bootprobleme ohne eine Shell zu debuggen, finde ich ziemlich gruselig. Gruss, Christian -- Christian Perlechris AT linuxinfotag.de 010111 http://chris.silmor.de/ 101010 LinuxGuitarKitesBicyclesBeerPizzaRaytracing
Re: Wrapper für /usr/bin/dpkg
Am 05.09.19 um 13:51 schrieb Heiko Schlittermann: Thomas Güttler (Do 05 Sep 2019 13:01:36 CEST): Es ist für mich binär: Es war erfolgreich (keine Warnungen) oder es war nicht erfolgreich, dann gibt es (neben der Fehlermeldung) keinen Output (du nennst es Betriebsdaten). http hat sich durchgesetzt. Da gibt es klare return-codes. Wenn man eine 200 bekommt, dann passt es und ich kann die Nutzdaten verarbeiten. Wenn ich zB eine 404 bekomme, dann weiß ich, dass in den Daten nur eine Fehlermeldung steht, also keine Betriebs/Nutzdaten. Das verstehe ich jetzt nicht. Command Line Applications haben eine klare Konvention, was Return Codes angeht. Und es liegt an Dir, Daten, die auf STDOUT erscheinen, zu ignorieren und Daten auf STDERR dann als beschreibende Details zum Fehler zu verstehen. Meine Meinung: Ein Ausgabekanal würde das deutlich einfacher machen. Es ist mir aber klar, dass das sich niemals nie mehr ändern wird. Ähnliche wie die Zeichenketten- terminieriung mit \0 in der Programmiersprache C. In meinem Kontext gibt es viel mehr http-Aufrufe als Aufrufe von Subprozessen deren stdout/stderr man auswertet. Und es ist gut, daß diese Dinge nicht jeder selbst implementieren muss, sondern daß genau dafür die Shell da ist, die unerwünschte und nicht unterdrückbare Betriebsausgaben nach /dev/null schickt. Linux und Shell sind zwei getrennte Dinge. Dank systemd ist es gar nicht so unvorstellbar einen Server zu betreiben auf der gar keine Shell installiert ist. Fände ich cool. Also ich verstehe das Problem noch nicht. Die Unix-Idee mit der Shell gibt mir die Flexibilität und schränkt mich nicht ein. Wenn man einen Subprozess hat und nur einen Kanal hat, dann kann man einfach mit read() lesen und warten bis alles da ist. Bei zwei Kanälen klappt das eben nicht. Da muss man dann mit select oder sonstigen async-io Spaß arbeiten. Alles machbar, aber deutlich mehr Aufwand. Das ist etwa wie "Shell vs Programmiersprache". Bei der Shell gibt es eine Warnung auf stderr und dann wird lustig die nächste Zeile ausgewertet. Da werde ich zum Autist. So kann Shell *ist* Programmiersprache. Was Du mit nächste Zeile meinst, weiß ich jetzt nicht, ob im Script oder bei der Verarbeitung der Daten. Die Shell¹ kennt „set -e“. Sehr nützlich. ich keine zuverlässigen Produkte erstellen. Die Shell wird bei mir nur noch interaktiv verwendet. Wichtiger sind aber automatisierte Tests. Wenn es davon genug gibt, dann ist es eigentlich egal wie die Implementierung arbeitet. Ob zuverlässig oder nicht, hängt sicher von der Aufgabenstellung ab. Ich denke, für Dein Eingangsproblem ist die Shell zuverlässig genug :) Und ich erkenne nicht, wie diese zwei Ausgabekanäle Deine automatisierte Auswertung erschweren - im Gegenteil, sie wird vereinfacht, weil Du eben Betriebsdaten (die Du vielleicht nicht unterdrücken kannst) von anderen Daten trennt. # C errno = 0; // to be safe int d = get_delta();// how to declare failure? if (errno) perror("delta") # Perl $d = get_delta(); # return undef on failure, details in $@ if (not defined $d) { die $@ }; # Go d, err := get_delta() // return err != nil on error if err != nil { fmt.Fatal(err) } Du schlägst gerade etwas vor, was dem von „C“ entspricht. (Nicht falsch verstehen, ich finde „C“ eine super Sprache, sollte jeder lernen, der was mit Programmieren tut.) In meinem Kontext werden bei Fehlern in der Regel Exceptions geworfen. Das „die()“ im Perl Beispiel kann wie eine Exception behandelt werden. In Go könnte man statt fmt.Fatal() mit panic() arbeiten, aber man hat da eine etwas andere Einstellung zu Fehlern. Nur die wirklichen „this should not happen“ sollten eine Panic erzeugen, andere sollten als diskreter Fehler an den Aufrufer zurückgeliefert werden. Aber das ist eine andere Baustelle als Dein Eingangsproblem, denke ich. Ja, das stimmt. Gruß, Thomas -- Heiko -- Thomas Guettler http://www.thomas-guettler.de/ I am looking for feedback: https://github.com/guettli/programming-guidelines
Re: Wrapper für /usr/bin/dpkg
Thomas Güttler (Do 05 Sep 2019 13:01:36 CEST): > Es ist für mich binär: Es war erfolgreich (keine Warnungen) oder es war nicht > erfolgreich, > dann gibt es (neben der Fehlermeldung) keinen Output (du nennst es > Betriebsdaten). > > http hat sich durchgesetzt. Da gibt es klare return-codes. Wenn man eine 200 > bekommt, dann passt > es und ich kann die Nutzdaten verarbeiten. Wenn ich zB eine 404 bekomme, > dann weiß ich, dass in den Daten nur eine Fehlermeldung steht, also keine > Betriebs/Nutzdaten. Das verstehe ich jetzt nicht. Command Line Applications haben eine klare Konvention, was Return Codes angeht. Und es liegt an Dir, Daten, die auf STDOUT erscheinen, zu ignorieren und Daten auf STDERR dann als beschreibende Details zum Fehler zu verstehen. Und es ist gut, daß diese Dinge nicht jeder selbst implementieren muss, sondern daß genau dafür die Shell da ist, die unerwünschte und nicht unterdrückbare Betriebsausgaben nach /dev/null schickt. Also ich verstehe das Problem noch nicht. Die Unix-Idee mit der Shell gibt mir die Flexibilität und schränkt mich nicht ein. > Das ist etwa wie "Shell vs Programmiersprache". Bei der Shell gibt es eine > Warnung auf stderr > und dann wird lustig die nächste Zeile ausgewertet. Da werde ich zum Autist. > So kann Shell *ist* Programmiersprache. Was Du mit nächste Zeile meinst, weiß ich jetzt nicht, ob im Script oder bei der Verarbeitung der Daten. Die Shell¹ kennt „set -e“. Sehr nützlich. > ich keine zuverlässigen Produkte erstellen. Die Shell wird bei mir nur noch > interaktiv verwendet. > Wichtiger sind aber automatisierte Tests. Wenn es davon genug gibt, dann ist > es eigentlich egal > wie die Implementierung arbeitet. Ob zuverlässig oder nicht, hängt sicher von der Aufgabenstellung ab. Ich denke, für Dein Eingangsproblem ist die Shell zuverlässig genug :) Und ich erkenne nicht, wie diese zwei Ausgabekanäle Deine automatisierte Auswertung erschweren - im Gegenteil, sie wird vereinfacht, weil Du eben Betriebsdaten (die Du vielleicht nicht unterdrücken kannst) von anderen Daten trennt. > > # C > > errno = 0; // to be safe > > int d = get_delta();// how to declare failure? > > if (errno) perror("delta") > > > > # Perl > > $d = get_delta(); # return undef on failure, details in $@ > > if (not defined $d) { > > die $@ > > }; > > > > # Go > > d, err := get_delta() // return err != nil on error > > if err != nil { > > fmt.Fatal(err) > > } > > > > Du schlägst gerade etwas vor, was dem von „C“ entspricht. (Nicht falsch > > verstehen, ich finde „C“ eine super Sprache, sollte jeder lernen, der > > was mit Programmieren tut.) > > In meinem Kontext werden bei Fehlern in der Regel Exceptions geworfen. Das „die()“ im Perl Beispiel kann wie eine Exception behandelt werden. In Go könnte man statt fmt.Fatal() mit panic() arbeiten, aber man hat da eine etwas andere Einstellung zu Fehlern. Nur die wirklichen „this should not happen“ sollten eine Panic erzeugen, andere sollten als diskreter Fehler an den Aufrufer zurückgeliefert werden. Aber das ist eine andere Baustelle als Dein Eingangsproblem, denke ich. -- Heiko signature.asc Description: PGP signature
Re: Wrapper für /usr/bin/dpkg
Am 04.09.19 um 16:45 schrieb Heiko Schlittermann: Manchmal denke ich mir, dass vieles deutlich einfacher wäre, wenn es nur stdout geben würde, und nicht noch stderr. Diese zwei Ströme machen es manchmal nervig. Du meinst das nicht ernst, oder :) Doch, ich meine das Ernst. Continuous Integration hat mich geformt und das ist gut so. Entweder alle Tests sind ok, oder ein oder mehrere Tests sind nicht ok. Das ist binär, da gibt es kein "vielleicht, naja, mal sehen". Genau diese zwei Ströme sind genial. Woher kannst Du sonst Betriebsdaten von Fehlermeldungen unterscheiden? Es ist für mich binär: Es war erfolgreich (keine Warnungen) oder es war nicht erfolgreich, dann gibt es (neben der Fehlermeldung) keinen Output (du nennst es Betriebsdaten). http hat sich durchgesetzt. Da gibt es klare return-codes. Wenn man eine 200 bekommt, dann passt es und ich kann die Nutzdaten verarbeiten. Wenn ich zB eine 404 bekomme, dann weiß ich, dass in den Daten nur eine Fehlermeldung steht, also keine Betriebs/Nutzdaten. Das ist etwa wie "Shell vs Programmiersprache". Bei der Shell gibt es eine Warnung auf stderr und dann wird lustig die nächste Zeile ausgewertet. Da werde ich zum Autist. So kann ich keine zuverlässigen Produkte erstellen. Die Shell wird bei mir nur noch interaktiv verwendet. Wichtiger sind aber automatisierte Tests. Wenn es davon genug gibt, dann ist es eigentlich egal wie die Implementierung arbeitet. In meinem Kontext werden bei Fehlern in der Regel Exceptions geworfen. Gruß, Thomas -- Thomas Guettler http://www.thomas-guettler.de/ I am looking for feedback: https://github.com/guettli/programming-guidelines
Re: Wrapper für /usr/bin/dpkg
Heiko Schlittermann (Mi 04 Sep 2019 16:45:03 CEST): > > Manchmal denke ich mir, dass vieles deutlich einfacher wäre, wenn es nur > > stdout geben würde, > > und nicht noch stderr. Diese zwei Ströme machen es manchmal nervig. > > Du meinst das nicht ernst, oder :) Diesen Satz würde ich gerne streichen, der Rest aber bleibt. -- Heiko signature.asc Description: PGP signature
Re: Wrapper für /usr/bin/dpkg
> Manchmal denke ich mir, dass vieles deutlich einfacher wäre, wenn es nur > stdout geben würde, > und nicht noch stderr. Diese zwei Ströme machen es manchmal nervig. Du meinst das nicht ernst, oder :) Genau diese zwei Ströme sind genial. Woher kannst Du sonst Betriebsdaten von Fehlermeldungen unterscheiden? signature.asc Description: PGP signature
Re: Wrapper für /usr/bin/dpkg
Hi Heiko und andere, Am 02.09.19 um 13:12 schrieb Heiko Schlittermann: 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? Der Aufrufer des Wrappers sieht keinen Unterschied. Die Zeichen kommen zeichenweise. Die Ausgabe für das Log-File wird gepuffert. Das ist für meinen Zweck voll ok. „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. Der Code des Aufrufer, der den Fortschrittsbalken liest ist nicht von mir, und lässt sich schwer ändern. Ist eben so. 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. Ich habe meinen Anwendungsfall gelöst und da passt alles prima in den RAM. Aber ich habe deine Bedenken verstanden. Prinzipiell könnten auch mehrere Gigabytes über stdout raus gehen. Manchmal denke ich mir, dass vieles deutlich einfacher wäre, wenn es nur stdout geben würde, und nicht noch stderr. Diese zwei Ströme machen es manchmal nervig. Gruß, Thomas -- Thomas Guettler http://www.thomas-guettler.de/ I am looking for feedback: https://github.com/guettli/programming-guidelines
Re: Wrapper für /usr/bin/dpkg
Thomas Güttler (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
Re: Wrapper für /usr/bin/dpkg
Am 30.08.19 um 23:24 schrieb Heiko Schlittermann: Thomas Güttler (Fr 30 Aug 2019 17:42:59 CEST): Ich bin froh so die Ursache des Fehlers gefunden zu haben. Hier der Code: https://github.com/guettli/wrap_and_log_calls Ich verstehe nicht viel von Py, aber es sieht mir so aus, als wenn Du erst die Daten sammelst und dann ins Log schreibst. Ist das gut? Warum nicht in der While True Schleife nach dem select gleich ins Log schreiben, was Du gelesen hast? Oder noch besser, stdout und stderr das Prozesses auf den fd des Logfiles legen und dann exec des gewünschten Kommandos. Analog zu #!/bin/sh exec "$@" 1>logfile 2>&1 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. 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. 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. 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"). 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. 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 Ich bin mir sicher, dass es möglich ist, dass auch in der Shell zu lösen. Gruß, Thomas -- Thomas Guettler http://www.thomas-guettler.de/ I am looking for feedback: https://github.com/guettli/programming-guidelines
Re: Wrapper für /usr/bin/dpkg
Thomas Güttler (Fr 30 Aug 2019 17:42:59 CEST): > Ich bin froh so die Ursache des Fehlers gefunden zu haben. > Hier der Code: https://github.com/guettli/wrap_and_log_calls Ich verstehe nicht viel von Py, aber es sieht mir so aus, als wenn Du erst die Daten sammelst und dann ins Log schreibst. Ist das gut? Warum nicht in der While True Schleife nach dem select gleich ins Log schreiben, was Du gelesen hast? Oder noch besser, stdout und stderr das Prozesses auf den fd des Logfiles legen und dann exec des gewünschten Kommandos. Analog zu #!/bin/sh exec "$@" 1>logfile 2>&1 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.) 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. -- Heiko signature.asc Description: PGP signature