notify / EvalSpecials / SemicolonEscape bug/problem/inkonsitenz

[justme1968]

sorry für den unhandlichen titel. mir ist nicht besseres eingefallen...

in diesem thread hier: https://forum.fhem.de/index.php/topic,55009.msg466339.html#msg466339 ist mir eben aufgefallen das es eine inkonsistenz zwischen der direkten eingabe auf der kommandozeile und der verwendung in einem notify gibt wenn man mehrere kommandos durch ; getrennt absetzt und sowohl das erste als auch das letzte in der liste ein shell oder perl aufruf sind.

ein beispiel:
- direkt auf der kommandozeile funktioniert

Code Auswählen Erweitern

"echo 1"; sleep 1; "echo 2" problemlos. im log landet 1 und nach einer sekunde 2.

- wenn man es aus einem notify heraus verwendet werden durch das SemicolonEscape in EvalSpecials die ; verdoppelt. das

Code Auswählen Erweitern

"echo 1";; sleep 1;; "echo 2" wird dann aber von AnalyzeCommandChain nicht mehr als drei kommandos interpretiert sondern als ein shell aufruf

Code Auswählen Erweitern

echo "1; sleep 1; echo 2" im log landet sofort

Code Auswählen Erweitern

1; sleep 1; echo 2


wenn man trickst und im notify noch ein ; anhängt:

Code Auswählen Erweitern

"echo 1"; sleep 1; "echo 2"; verdoppelt SemicolonEscape die ; nicht und alles funktioniert.

die frage ist warum ruft EvalSpecials SemicolonEscape auf?

mir fallen noch mehr fälle ein bei denen die verdoppelten ; die sonst meist nicht auffallen probleme machen würden.  auch wenn es keine folge mehrere shel oder perl kommandos ist sondern nur ein einziges.

[rudolfkoenig]

die frage ist warum ruft EvalSpecials SemicolonEscape auf?

Ich glaube das ist die falsche Frage: EvalSpecials ruft sie auf, weil EvalSpecials aus notify ins fhem.pl gewandert ist, und notify SemicolonEscape irgendwo aufrufen musste Die Frage ist eher, wozu SemicolonEscape gut ist: damit AnalyzeCommandChain Konstrukte wie {a;b} nicht in Einzelteile zerlegt.

Ich habe ja nicht umsonst Sorgen beim mischen von FHEM/Perl/Shell Befehlen, offiziell ist in einem AnalyzeCommandChain Parameter (also at/notify/etc Befehl) nur eine Sorte (Perl/Shell/FHEM) Befehl erlaubt.

Wenn jemand eine bessere und nicht uebermaessig schwerfaellige Loesung kennt, nur her damit.

[justme1968]

ich schau mal ob man mit parseParams nicht die zusammengehörenden " bzw. {} paare finden kann und dann nur nur dazwischen verdoppelt und nicht mehr zwischen den kommandos.

wobei ja bei eingabe in der kommandozeile nicht automatisch verdoppelt wird. nur im notify. exakt der gleiche code verhält sich also unterschiedlich. je nach dem von wo er verwendet wird. auch wenn es die falsche frage ist ist es also zumindest immer noch inkonsistent

[rudolfkoenig]

auch wenn es die falsche frage ist ist es also zumindest immer noch inkonsistent

Das es "kaputt" ist, habe ich nie bestritten

[justme1968]

anbei ein erster vorschlag wie man die kommandozeile verarbeiten könnte um das problem mit den ; in den griff zu bekommen.

noch nicht als patch sondern als standalone test. am anfang stehen die testfälle die mir eingefallen sind. vermutlich gibt es noch mehr die man man durch schicken sollte.

ich habe es in eine neue routine gesteckt statt parseParams zu erweitern. die beiden sind zwar sehr ähnlich, unterm strich ist es aber übersichtlicher beide getrennt zu lassen statt zu versuchen alles in einer routine zu erschlagen.

die idee ist in AnalyzeCommandChain die splitCmdList routine aufzurufen statt dem einfachen split.

die aktuellen features sollten sein:
- es ist nicht mehr nötig ; zu verdoppeln. nirgendwo.
- trotzdem verdoppelte ; zwischen kommandos werden ignoriert
- das SemicolonEscape kann entfallen
- SeMiCoLoN ersetzen kann entfallen
- leerzeichen am anfang und ende eines kommandos werden entfernt
  -> die nachfolgende erkennung von "..." und {...} wird sicherer
- das mischen von fhem, perl und shell kommandos in einer kommandozeile ist möglich
- kommandozeile und notify/at verhalten sich identisch


die vorgeschlagene version sollte so mit allen aktuell möglichen kommandozeilen klar kommen, aber zusätzlich auch noch mit anderen sinnvollen die zur zeit nicht gehen.


ps: vermutlich habe ich noch alle möglichen sonderfälle übersehen...

[rudolfkoenig]

- es ist nicht mehr nötig ; zu verdoppeln. nirgendwo.

Das glaube ich nicht. Zugegebenermassen ist das folgende Beispiel nicht sehr sinnvoll, demonstriert aber die Zweideutigkeit, was das Programm ohne einen Hinweis nicht aufloesen kann:

Code Auswählen Erweitern

define a notify a sleep 10;; set x y; trigger a b
Trotzdem waere ich froh, wenn wir den Anzahl der benoetigten Strichpunkte reduzieren koennten.

ps: vermutlich habe ich noch alle möglichen sonderfälle übersehen...

Da bin ich sicher, und das Problem ist, dass die Meute hier sich nicht die Muehe macht, dein Code zu testen, und uns fallen scher nicht alle Sonderfaelle ein. Wenn du bereit bist, dann werde ich es aktivieren, und dann ein paar Tage lang Sonderfaelle fixen. Notleidende muesse ein restore machen, optional per featurelevel hilft mAn nicht.

[justme1968]

du hast recht. das nirgendwo war zu optimistisch . dieser fall wurde noch gar nicht berücksichtigt.
die zweideutigkeit kommt nicht von den ; an sich sondern davon das ein teil zum kommando davor gehört. eigentlich müsste man das in dieser art auflösen:

Code Auswählen Erweitern

define a notify a 'sleep 10; set x y'; trigger a bdas wäre aber eine echte syntax änderung.

ich habe die version oben noch mal etwas abgeändert. damit kann man dein beispiel auch abdecken.

bereit ja. aber ich mache selber noch ein paar test und ich hätte schon gerne noch ein paar augen mehr vorher mal darüber schauen. vor allem bei DOIF könnte es sein das es noch seiteneffekte gibt.

optional machen funktioniert glaube ich tatsächlich nicht, aber ich könnte mir vorstellen das man dreistufig vorgeht:
1. alte und neue version werden verwendet, die alte wird ausgeführt, bei abweichungen gibt es eine deutliche meldung im log
2. wie 1., aber die neue wird ausgeführt
3. nur noch die neue

[rudolfkoenig]

Ja, so im nachhinein Syntaxaenderungen einfuehren zu koennen waere was feines. Deinen Plan finde ich uebrigens gut.
Weitere Testfaelle:

Code Auswählen Erweitern

"ls -l "fhem.pl"; ls -l "fhem.pl""
{ Log 1, "{1}" }; Log 1, "{2}"; }


[rudolfkoenig]

Sorry, der letzte Testfall sollte folgendes sein:

Code Auswählen Erweitern

{ Log 1, "1}" ; Log 1, "2"; }

[justme1968]

Code Auswählen Erweitern

{ Log 1, "1}" ; Log 1, "2"; }ja. hier habe ich aber noch keine idee. ausser das es mit der aktuellen version auch nicht geht und nicht schlimmer wird.

Code Auswählen Erweitern

"ls -l "fhem.pl"; ls -l "fhem.pl""wenn man eine formale syntax aufstellen würde wäre das hier zumindest sehr zweifelhaft. man kann die zusammengehörenden " nicht wirklich zuverlässig erkennen. hier gilt auch das es mit der aktuellen version auch nicht geht.

1. könnte man durch besseres zählen in den griff bekommen -> wollen wir das ?

2. lässt sich als

Code Auswählen Erweitern

"ls -l fhem.pl; ls -l fhem.pl" oder

Code Auswählen Erweitern

"ls -l 'fhem.pl'; ls -l 'fhem.pl'" schreiben.

in beiden fällen kann man fhem auch immer noch mit explizit verdoppelten ;; unter die arme greifen.

ich denke es lassen sich ohne eine formale syntax immer zweideutige fälle finden bei denen der einfache parser etwas anderes ausspuckt als die interpretation die ein mensch liefern würde. und auch bei der menschlichen interpretation muss man dann unterscheiden zwischen dem was eine normalen anwender erwarten würde und das was ein entwickler automatisch sieht.


so lange keine aktuell gültigen varaiten nicht mehr gehen und gleichzeitig viele der eindeutigen fälle keine verdoppelung mehr brauchen würde ich sage das es eine verbesserung ist.

[justme1968]

Code Auswählen Erweitern

{ Log 1, "1}" ; Log 1, "2"; }geht jetzt auch.

den fall kann man erschlagen in dem man im zweifel lieber mehr als weniger zusammen sucht. wenn es ein gültiger ausdruck sein soll muss am ende ein } kommen. das ist zwar nicht hinreichend aber notwendig.

einen patch um das oben vorgeschlagene vorgehen umzusetzen habe ich auch fertig. kommt demnächst.

und dann schauen wir mal...

[justme1968]

anbei ein vorschlag für die erste stufe.

bei abweichungen zwischen alter und neuer variante wird erst mal nur eine log meldung erzeugt. es wäre aber trotzdem schön wenn es ein paar tester vor dem einchecken probieren.

[rudolfkoenig]

ausser das es mit der aktuellen version auch nicht geht und nicht schlimmer wird.

Protest! In beiden Faellen kann ich in der alten Version mit ;; oder ; steuern, wo es getrennt werden soll. Wenn das manuelle Eingreifen in der neuen Version auch funktioniert, dann habe ich kein Problem damit, dass das sie nicht immer perfekt liegt.
Mt dem Einchecken warte ich noch solange, bis ein Dritter was dazu sagt. Dritter, teste mal auch

[justme1968]

In beiden Faellen kann ich in der alten Version mit ;; oder ; steuern, wo es getrennt werden soll.

genau das meinte ich mit 'nicht schlimmer wird' das geht genau so weiter.

die neue version ist nicht perfekt aber in vielen einfachen fällen besser. so auch bei den ganz oben ursprünglich angesprochenen fällen.

bei komplizierten fällen kann man wie früher immer noch mit ;; nach helfen.

[DeeSPe]

Gibt es zu diesem Thema hier noch Bemühungen?

Ich möchte dieses Thema noch einmal nach oben holen da ich gerade mit dieser Thematik kämpfe!
In dem Modul HouseMode, welches ich gerade in Entwicklung habe, soll es möglich sein auszuführende Befehle per Attribut einzugeben.
Es soll eben auch möglich sein FHEM Code und Perl Code wild zu mischen ala:

Code Auswählen Erweitern

set bla bla;
{fhem "define -temporary atTmp_Heizung_aus at +00:30 set Heizung off" if ("%SEASON%" ne "summer")};
set bla1 bla bla;
{<ANDERER PERLCODE>};
{fhem "................."}

Laut meinen bisherigen Tests klappt das bisher leider nicht zuverlässig, ich nehme an wegen der Semikolon Problematik!?

Würde mich sehr freuen wenn eine Lösung gefunden würde...

Gruß
Dan