Am 05.09.19 um 13:51 schrieb Heiko Schlittermann:
Thomas Güttler guettliml@thomas-guettler.de (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