Exit code von fhem.pl immer 0

[diddle]

Huhu zusammen,

ich würde gern fhem-Kommandos aus nem anderen Skript per fhem.pl aufrufen. Leider kann man schlecht den Erfolg auswerten, da der Exit-Code immer 0 (=OK) ist?

$ /opt/fhem/fhem.pl 7072 bla
Unknown command bla, try help.
$ echo $?
0

Wäre super, und auch konsistenter, wenn das geändert werden könnte, oder?

Gruß und Dank im Voraus!
Diddle.

[viegener]

Im Prinzip ist der return code ein Zeichen dafür ob fhem.pl erfolgreicih war. Allerdings ist Erfolg hier ein Zeichen dafür ob sich der Aufruf erfolgreich mit dem Server verbinden konnt.

Der von Dir beschriebene Aufruf führt ja nicht selbst das fhem Kommando aus, sondern verbindet sich zum telenet port (7072) und dann wird im Server das Kommando ausgeführt. Dabei stellt sich die Frage, was in diesem Fall Erfolg ist...

Wenn fhem.pl ein normales Skript, dass lokal die Operation ausführen würde wäre Deine Erwartung korrekt.

[diddle]

Hi,

danke für die Antwort... ok, kann man so oder so sehen.
Natürlich gibt es unterschiedliche exit-Codes, die gern genutzt werden dürfen. 

Die ssh schickt z.B. den Exit-Code des Remote-Commands durch zum Client. Bei fatalen Fehlern (Remote-System nicht erreichhbar bspw. kommt ein 255).

$ ssh user@remotehost "echo remote exit 1; exit 1"
remote exit 1
$ echo $?
1

$ ssh user@remotehost "echo remote exit 0; exit 0"
remote exit 0
$ echo $?
0

$ ssh user@remotehost "echo remote exit 10; exit 10"
remote exit 10
$ echo $?
10

$ ssh user@xxx "echo huhu"
ssh: xxx: Name or service not known
$ echo $?
255

Ist schon praktisch so. 

Wenn schon der Exit-Code nicht genommen werden kann, sollte sauber stdout und stderr getrennt werden... ist aber auch nicht so. Fehler kommen auch auf stdout. Und in dem stdout kommt nichts vor (bspw. "Error:"), was ich konsequent als Fehler erkennen kann.

Wie gesagt: Nutzbarer Exit-Code wäre das tollste.

Gruß
Diddle.

[viegener]

Hi,

danke für die Antwort... ok, kann man so oder so sehen.
Natürlich gibt es unterschiedliche exit-Codes, die gern genutzt werden dürfen. 

Die ssh schickt z.B. den Exit-Code des Remote-Commands durch zum Client. Bei fatalen Fehlern (Remote-System nicht erreichhbar bspw. kommt ein 255).

$ ssh user@remotehost "echo remote exit 1; exit 1"
remote exit 1
$ echo $?
1

$ ssh user@remotehost "echo remote exit 0; exit 0"
remote exit 0
$ echo $?
0

$ ssh user@remotehost "echo remote exit 10; exit 10"
remote exit 10
$ echo $?
10

$ ssh user@xxx "echo huhu"
ssh: xxx: Name or service not known
$ echo $?
255

Ist schon praktisch so. 

Wenn schon der Exit-Code nicht genommen werden kann, sollte sauber stdout und stderr getrennt werden... ist aber auch nicht so. Fehler kommen auch auf stdout. Und in dem stdout kommt nichts vor (bspw. "Error:"), was ich konsequent als Fehler erkennen kann.

Wie gesagt: Nutzbarer Exit-Code wäre das tollste.

Gruß
Diddle.

Genau wie Du sagst, dass kann man so oder so sehen.

Ich denke aber auch bei der Frage stderr/stdout kann man unterschiedliche Positionen haben. Generell würde ich sagen, FHEM ist kein shell-programm und kein normales shell-skript, sondern ein Server-Programm der neben einer telnet-Schnittstelle vor allem Web-schnittstellen bietet. Meines Wissens haben telnet und auch das Web kein Konzept für stderr als separaten Stream.

Ich denke aber Dein Problem geht noch weiter, weil u.U. der Erfolg eines Befehls nur im Event-Stream abzusehen ist und der Fehler nur im Logfile. Es gibt keinen durchgängigen Ansatz für output/stderr von Kommandos in Modulen (eher sehr rudimentär) wie er bei commandline-tools vorhanden ist.

Meine persönlich Meinung ist, dass der grundlegende FHEM-Ansatz über events eine Kopplung von Modulen vorzunehmen ist ein exzellentes und sehr gutes Konzept ist.