[gelöst] Shell Befehl qx() non-blocking ausführen?

[FHEMAN]

Hallo zusammen,

bei Shell Kommandos kann man ja ein Blockieren des Systems mittels "&" am Befehlsende quasi verhindern.
Ich habe das in folgendem qx Aufruf probiert, jedoch blockiert mein FHEM trotzdem und perfmon schlägt an:

Code Auswählen Erweitern

my $smstext = qx(sudo /usr/bin/gnokii --getsms SM 0 2>&1 &)
(mit gnokii sende und empfange ich SMS; in diesem Fall wird der SMS Speicherplatz 1 ausgelesen.)

Gibt es bei qx() auch einen Parameter, der trotz Rückgabewert ein Blockieren verhindert? Bevor ich auf eine zweite FHEM Instanz ausweiche, wollte ich die Frage hier lieber noch einmal stellen..

Danke für eure Hilfe
Ronny

[justme1968]

rückgabewert und non blocking lässt sich so nicht kombinieren.

entweder kompliziert mit NonBlocking.pm oder einfach in dem man nicht direkt die rückgabe abwartet sondern auf shell seite nach dem das kommando durch ist das ergebnis zurück an fhem meldet. mit nc oder fhem aufruf.

dann kann man auch das qx durch "..." ersetzen und hat auch gleich noch die log ausgaben im fhem log.

gruss
  andre

[FHEMAN]

Hallo Andre,
meinst du das so, dass ich dann aus FHEM heraus eine .sh Script Datei aufrufe, die alles enthält, unter anderem auch
/opt/fhem/fhem.pl 7072 "setreading sms $smstext"
?
Aber es wird dann doch trotzdem auf die Rückgabe vom gnokii Aufruf gewartet?

Hast du evtl. ein konkreteres Beispiel für mich? Oder ein paar Wortfetzen, nach denen ich hier forumsuchen kann? ("nc" war nicht so wirklich ergiebig)

Gruß
Ronny

[justme1968]

genau so. oder statt fhem.pl mit echo "setreading sms $smstext" | nc <ip> 7072

das script rufst du in fhem mit "xxx.sh" auf (inklusive der " ). da wird nicht gewartet sondern es passiert asynchron im hintergrund.

gruss
  andre

[FHEMAN]

Ich benötige noch einen Schritt davor: Wie bekomme ich den Output in eine Variable?
SMSINBOX=`sudo /usr/bin/gnokii --getsms SM 0 2>&1 &` oder SMSINBOX="sudo /usr/bin/gnokii --getsms SM 0 2>&1 &" mit oder ohne & oder &1 am Ende funktioniert irgendwie nicht.

//edit: OK, ich habs,  das 2>&1 gehörte scheinbar zusammen. Ohne dem geht es nun.

[FHEMAN]

Argh, für einen Linux Noob sind hier aber auch ein paar Hürden versteckt... ich wollte nun mit fhem.pl das cmd absetzen
sudo /opt/fhem/fhem.pl 7072 setreading sms rawdata 12345
Auch wie in der Commandref beschrieben mit doppelten "" wird das Reading nicht geändert. Es gibt aber auch keine Fehlermeldung in der Shell.
Argh!

[FHEMAN]

Ja, man könnte in der Commandref noch erwähnen, dass bei gesetzten Telnet Passwort der Aufruf so aussehen muss:
sudo /opt/fhem/fhem.pl 7072 PASSWORT setreading sms rawdata 12345

So weit, so trial and error. Das nächste Ding ist nicht, dass das Ganze scheinbar noch in `` gesetzt werden muss, sonder mein Rückgabewert kann nicht in ein Reading transformiert werden - aufgrund mehrerer Zeilen? Ich weiß gerade nicht, wo ich anfangen soll, das Problem genauer zu beschreiben. Für heute habe ich eh erstmal die ** voll. Hoch lebe Windows!!

[rudolfkoenig]

mein Rückgabewert kann nicht in ein Reading transformiert werden - aufgrund mehrerer Zeilen?

Dazu kann man alles mit einer zweiten SMSINBOX=`echo $SMSINBOX` auf eine Zeile umbauen. Oder man versieht das Zeilenende mit \ mit SMSINBOX=`echo "$a" | sed 's/$/\\/'`.
Die zweite Variante ueberlebt erst ab dem update morgen einen FHEM-Restart, da mehrzeilige Readings bzw. Events unerwuenscht sind. Benutzer sollen Attribute setzen, z.Bsp. comment

Hoch lebe Windows!!

Frei nach dem Motto: wozu Grundlagen lernen um Probleme selbst loesen zu koennen, lieber ist man dem Hersteller ausgesetzt. Mag je nach Aufgabe sogar die richtige Loesung sein.

[Prof. Dr. Peter Henning]

Hoch lebe Windows!!

Nun ja, jeder so, wie er kann.

LG

pah

[FHEMAN]

Ja mei.. immer drauf auf die Windows User! Mit der Powershell wäre ich ganz sicher schneller. Die Linux Shell ist für mich eher ein kleines Mysterium. Was ich in den letzten Monaten wirklich schönes auf diversen Einplatinencomputern durch Zusammenklauben installiert und konfiguriert habe... 1-2 Jahre später schaue ich hier bestimmt wie ein Schwein ins Uhrwerk aber back to topic.

Danke, Rudi, für den Tipp samt Implementierung; dann teste ich deine zweite Variante gerne morgen einmal.
...und bin gespannt auf die nächsten Baustellen. Aber dank der netten User, die auch zur Thematik antworten , schaffe ich das bestimmt.

[CoolTux]

Du kannst doch fhem auf Windows laufen lassen, oder Windows auf dem Pi installieren. Soll wohl angeblich gehen. Und "die Linux Shell" gibt es nicht. Es gibt eine Menge Kommandozeileninterpreter für nix basierte Systeme. Darunter auch die Bourne-again shell die Du wohl meinst.

[FHEMAN]

Auch wenn es sicherlich sogar headless ginge, es ist schon gut so, wie es ist (mit Linux) (kriege ich jetzt auch ein paar Likes?? )

Jedenfalls ist genau das der Grund, weswegen ich nur ungern auf sh Scripte und cronjobs etc. auf OS Ebene ausweiche, sondern weitestgehend alles in FHEM löse. Das ist für mich besser verständlich, überschaubar und transportabel. ...Um mal den Kreis der Bourne Verschwörung mal wieder zum Thema zu schließen, ob man einen shell Befehl in ein FHEM Konstrukt inkl. nonblocking.pm verpacken kann.
Bin da wohl mal wieder der einzige oder keiner will seine Insellösung preisgeben?

[rudolfkoenig]

Bin da wohl mal wieder der einzige oder keiner will seine Insellösung preisgeben?

Ich vermute Du bist der Erste, der die mehrzeiligen Rueckgabewerte eines laenger laufenden Shell-Programmes in einem Reading haben will. Als Beweis habe ich, dass bis gestern fhem.pl mehrzeilige Readings nicht unterstuetzt hat. Ich meine, in dieser Diskussion sind alle Zutaten fuer die Umsetzung beschrieben. Ueblicherweise fasst der Thread-Ersteller dann die Loesung zusammen, manche machen sogar einen fhemwiki Eintrag.

[CoolTux]

Und ich habe meine Insellösung hier im Forum mal kunt getan. War im Zusammenhang mit lepresence und gatttool zum Batterie auslesen von G-Tags.
Ich schau mal im Laufe des Tages.

[CoolTux]

Bittel schön

https://forum.fhem.de/index.php/topic,28753.msg501336.html#msg501336

Bei Fragen einfach fragen.