Hallo Rudi,
in den vergangenen Tagen sind wir hier im Forum zwei Mal auf das Problem gestoßen, dass setKeyValue() klaglos einen mehrzeiligen Wert in das keyFile schreibt, der dann aber mit getKeyValue() nicht mehr gelesen werden kann, weil die Auswertung beim Lesen zeilenweise erfolgt, was durchaus Sinn macht.
Insbesondere, wenn ein Modul mit MIME::Base64::encode() arbeitet, kommt es z.B. bei längeren secrets zu dem beschriebenen Phänomen, weil die Funktion standardmäßig nach 76 Zeichen ein \n einfügt und damit den Zeilenumbruch verursacht. Man kann das in der Funktion durch die Angabe eines Leerstrings als Parameter unterbinden, muss es aber auch tun. Bei JsonMod gab es eine entsprechende Anpassung.
Nun könnte man überlegen, in fhem.pl
- setKeyValue() dazu zu bringen, evtl. vorhandene \n durch '' zu ersetzen, um diesen Wert zu speichern
- analog zu 1.) ein vorhandenes \n durch irgendwas "spezielles" zu ersetzen, das beim Lesen mit getKeyValue() wieder durch ein \n ersetzt wird
- setKeyValue() das Schreiben eines mehrzeiligen Wertes mit einer Fehlermeldung ablehnen zu lassen
- gar nichts zu tun
Bei 1.) besteht ein gewisses Restrisiko, den übergebenen Wert "falsch" zu verändern. Aber er ist ja sowieso aufgrund des \n unbrauchbar.
Bei 4.) würde ich sagen, das wäre unschön, wenn man die mögliche Problemstelle kennt und nicht reagiert.
Eigentlich kann ich mir kein Szenario vorstellen, in dem ein Zeilenumbruch an dieser Stelle wirklich gewollt sein könnte.
Vielleicht magst Du in einer ruhigen Minute einmal darüber nachdenken, ob man an dieser Stelle etwas verbessern kann.
Jetzt brauche ich nur noch eine Idee, wie ich neu kodierte Zeilen von alten Zeilen unterscheiden kann.
Kannst du bitte einen der Problem-Threads hier verlinken?
Ich habe mich nach etwas gruebeln fuer 3. entschieden.