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
Wrapper für /usr/bin/dpkg
Hallo, salt-stack zeigt mir nicht stdout/stderr des dpkg-Aufrufs an. Es kommt zu einem Fehler, aber ich habe keine Ahnung was los ist. Was tun? Ich habe hier einen Wrapper geschrieben, der eine Log-Datei erzeugt, und der Aufrufer bekommt gar nicht mit, dass er nicht dpkg sondern meinen Wrapper aufruft. Funktioniert mit kleinen Anpassungen für alle Befehle, nicht nur dpkg. Ich bin froh so die Ursache des Fehlers gefunden zu haben. Hier der Code: https://github.com/guettli/wrap_and_log_calls Eins ist klar. Salt-stack ist großer Mist. Das nächste mal nehme ich Ansible. Feedback ist willkommen, Thomas -- Thomas Guettler http://www.thomas-guettler.de/ I am looking for feedback: https://github.com/guettli/programming-guidelines
