Problem mit update / httputils

[Sidey]

Hallo,


ich habe ein Problem mit dem update über eine eigene controls Datei.
Ehrlich gesagt, bin ich ziemlich ratlos. Ich vermute es liegt an einem Fehler im httpsutils Modul aber so ganz sicher bin ich mir nicht.

Folgendes wird in FHEM aufgerufen:

Code Auswählen Erweitern

update force https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/controls_signalduino.txt


In FHEM erscheint dann:

Code Auswählen Erweitern

UPD FHEM/14_SIGNALduino_AS.pm

https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/FHEM/14_SIGNALduino_AS.pm
: empty file received

Den Link kann ich problemlos im Browser öffnen. Die Datei hat Daten.
Mit wget und curl bekomme ich die Datei auch auf meinem Raspberry Pi.

Auf der Konsole (getestet unter Windows) erscheint folgendes:

Code Auswählen Erweitern


2015.09.06 22:30:57 4: HttpUtils url=https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/controls_signalduino.txt
2015.09.06 22:30:58 1: PERL WARNING: Use of uninitialized value in bitwise or (|) at Z:/Programme/perl/lib/IO/Socket/SSL.pm line 2181.
2015.09.06 22:31:00 4: https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/controls_signalduino.txt: HTTP response code 200
2015.09.06 22:31:00 4: HttpUtils https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/controls_signalduino.txt: Got data, length: 702
2015.09.06 22:31:00 4: Got remote controlfile with 12 entries.
2015.09.06 22:31:00 4: HttpUtils url=https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/CHANGED
2015.09.06 22:31:00 4: https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/CHANGED: HTTP response code 200
2015.09.06 22:31:00 4: HttpUtils https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/CHANGED: Got data, length: 2890
2015.09.06 22:31:00 1: UPD FHEM/14_SIGNALduino_AS.pm
2015.09.06 22:31:00 4: HttpUtils url=https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/FHEM/14_SIGNALduino_AS.pm
: HTTP response code 400ttps://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/FHEM/14_SIGNALduino_AS.pm
: Got data, length: 0: HttpUtils https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/FHEM/14_SIGNALduino_AS.pm
: Zero length data, header follows:tps://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/FHEM/14_SIGNALduino_AS.pm
: empty file received: https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/FHEM/14_SIGNALduino_AS.pm
2015.09.06 22:31:00 4: 19136:FHEMWEB:127.0.0.1:65329: /fhem&cmd=update+force+https%3A%2F%2Fraw.githubusercontent.com%2FRFD-FHEM%2FRFFHEM%2Fdev-cresta%2Fcontrols_signalduino.txt / RL:1236 / text/html; charset=UTF-8 / Content-Encoding: gzip


Irgendwie kann er also die Daten im Ordner FHEM nicht laden, bzw. mit dem Request stimmt was nicht, da der Server ja mit einem Code 400 antwortet.

Ich habe einfach keine Idee, woran es liegt. In einem anderen Branch habe ich eine funktionierende Konstellation. Prinzipiell ist mein Aufruf also nicht falsch.
Da ich nicht alleine mit dem Fehler bin, liegt es wohl nicht an meinen Systemen. Ich vermute den Fehler irgendwo in der controls Datei oder aber im httputils Modul.

Grüße Sidey

[rudolfkoenig]

Statt force wuerde ich all verwenden, ist weniger martialisch.
Sonst handelt es sich um ein DOS-Line-Ending Problem in der control-Datei.

[Sidey]

Hallo Rudolf,

jo verstehe... Zeilenumbruch.
Hmm, könnte man durch ne kleine Regex ja heraus filtern oder was meinst Du?

Grüße Sidey

[rudolfkoenig]

Ich meine, dass CR+NL in FHEM nichts zu suchen hat.

[Sidey]

Ja, habe ich gemerkt, aber httputils filtert aktuell nicht auf valide Zeichen in einer URL...

[Sidey]

Hallo,

Obwohl ich die control Datei jetzt über ein Perl Script erstelle, läuft perl unter windows dann erzeugt es \r\n als Zeilenumbruch.

Da Perl aber beim Einlesen durchaus so schlau ist, beides als Zeilenumbruch erkennen zu können, schlage ich folgenden Patch vor um Update etwas robuster zu machen.



Grüße Sidey

[betateilchen]

Du brauchst doch in Deinem Skript einfach nur mit binmode zu arbeiten, dann klappts auch unter Windows *würg* mit den Zeilenumbrüchen.

[Sidey]

Hallo Betateilchen,

okay das mit binmode funktioniert, das war mir so nicht bewusst.
Ich denke der Patch ist aber trotzdem nicht verkehrt.

Grüße Sidey

[rudolfkoenig]

Doch, es ermutigt naemlich auch im Quellcode das einfuegen von DOS-Zeilenenden, was erstens in meinem Editor haesslich aussieht, und zweitens eine weitere Fehlerusache ist. Meiner Ansicht nach kann man einem Entwickler zumuten, Dateien ohne DOS-Zeilenenden zu produzieren, bei den FHEM-Modulen wird das auch untersagt.

[Sidey]

Moin,

ich weiss nicht, wieso es jemanden ermutigt etwas verkehrt zu machen, wenn ein Programm etwas Fehler toleranter ist. Ich hatte es eher als Feature gesehen.
Mir war auch nicht bewusst, dass man keine Windows line Endings in irgend einer Art und weise mit Fhem verarbeiten soll. Bzw, dass man solche Daten gar nicht erst abfragen soll.

Ich habe einen Vorschlag gemacht, da ich nicht wusste, dass CR NL ein Problem Darstellen.
Eine Log Ausgabe mit dem Hinweis CR LF ist nicht supportet hätte mir sicher auch geholfen. Vielleicht steht es auch irgendwo im Wiki, aber den Punkt habe ich dann wohl übersehen.
Ich habe mir jetzt einen Workaround geschaffen und schreibe direkt mittels bin mode in eine Datei. Über die Umleitung der Konsole in eine Datei geht es ja unter Windows nicht.

Ich brauche den Patch nicht mehr, da ich mir mittlerweile der Problematik bewusst geworden bin und die Daten, welche ich für den HTTP Get bereitstelle angepasst habe.

Die Festlegung "CR NL ist nicht erlaubt" kommt mir aber schon etwas komisch vorkommt, da FHEM ja durchaus auch unter Windows funktioniert und die controls Datei von extern geladen wird.

Folgende Zeile aus 98_Update verstehe ich in dem Zusammenhang dann aber nicht mehr:

Code Auswählen Erweitern

@locList = map { $_ =~ s/[\r\n]//; $_ } <FD>;

Wenn ich nicht ganz falsch liege, dann  wird entweder doch was mit CR LN abgelegt, oder die Zeile ist nicht ganz korrekt.
Mag aber auch sein, das ich hier auf dem Schlauch stehe.


Grüße Sven

[rudolfkoenig]

Es geht nicht darum, dass FHEM unter Windows nicht funktionieren soll, sondern darum, dass _Entwickler_ ProgrammCode nicht beliebig gestalten sollen. Die erwaehnte Zeile stammt vom vorherigen Modul-Maintainer, der offensichtlich meine Marotte nicht hatte, weiterhin liest sie lokale Dateien ein, die evtl. ein Benutzer unter Windows angefasst haben koennte. Wg. der fehlenden Fehlermeldung: ich weiss nicht genau, wieviele Leute, die fuer FHEM ThirdParty Module anbieten unter Windows arbeiten. Ich tippe auf eins. Der hat wiederum diese Marotte jetzt mitgekriegt.

[herrmannj]

Hi,

ich lese erstaunt mit, betrifft mich auch.

Bisher habe ich mich über gelegentliche, seltene, gleich lautende, Berichte gewundert und das immer als fhem-update Unzulänglichkeit abgetan ohne die Ursache zu kennen. Generell arbeite ich unter linux, benutze aber gelegentlich auch Orionhub.

Fehlerbild: "empty file received" (oder so) - im Browser wird dir control datei angezeigt.

Für die unter linux erstellten commits sollte das also eigentlich nicht die Ursache sein - das müsste man dann doch untersuchen ...
Auf Orionhub habe ich keinen Einfluss. Da ich auch selber die updates dann so beziehe und den Fehler (linux host(s) fhem) nicht erhalte ist doch vielleicht noch mehr. (?)

Ich würde es eigentlich ganz gut finden fhem-update in dieser Beziehung doch etwas zu "härten". Sind da Nachteile / Nebeneffekte zu erwarten ?

vg
joerg

[rudolfkoenig]

Es geht hier um die (sinnvollerweise automatisch generierte) Datei controls.txt, welcher mAn nicht mit CR/NL verunstaltet sein sollte.
Wenn man die Generierung der Datei nicht unter Kontrolle hat, dann macht man mAn was falsch.

Aber bevor mir diese Diskussion zuviel Energie kostet, habe ich den von Sven vorgeschlagenen Patch eingespielt.

[herrmannj]

ja, hast recht. Danke.

Irgendwas (Bauchgefühl) sagt mir das da vmtl noch was ist. Bei mir lief das update immer was ja dann garnicht so gewesen sein dürfte ..

Ich warte mal ob nochmal Berichte dazu auftreten dann kann man ja nochmal graben

danke und vg
joerg

[betateilchen]

Meiner Ansicht nach kann man einem Entwickler zumuten, Dateien ohne DOS-Zeilenenden zu produzieren, bei den FHEM-Modulen wird das auch untersagt.

*unterschreib*

Es ist m.E. nicht die Aufgabe von fhem, jeden Mist, den irgendjemand ausserhalb von fhem produziert, wieder gradezubiegen.

Aber bevor mir diese Diskussion zuviel Energie kostet, habe ich den von Sven vorgeschlagenen Patch eingespielt.

Sehr bedauerlich.