fhem.pl: lustiger Namespace-Bug

[RichardCZ]

Also, dass der main Namespace in FHEM ja ziemlich überfüllt ist, muss ich ja wohl nicht extra weiter breittreten.

Und über die daraus resultierende grenzwertige Wartbarkeit haben wir schon an anderer Stelle gesprochen, aber irgendwie blieb das ja alles im theoretischen Bereich. Nun - hier was Konkretes:

Code Auswählen Erweitern

sub
restoreDir_saveFile($$)
{
  my($restoreDir, $fName) = @_;

  return if(!$restoreDir || !$fName);

  my $root = $attr{global}{modpath};
  restoreDir_mkDir($root, "$restoreDir/$fName", 1);
  if(!copy($fName, "$root/$restoreDir/$fName")) {
    log 1, "copy $fName $root/$restoreDir/$fName failed:$!";
  }
}

Finde den Fehler.

Bevor die schnelle Auflösung kommt, sage ich wie ich ihn gefunden habe. Ich lese natürlich viel und gerne und irgendwie war mir POSIX zu allem Namespace-Überfluss dann doch zuviel des Guten. Ich zitiere aus https://perldoc.perl.org/POSIX.html

Everything is exported by default (with a handful of exceptions). This is an unfortunate backwards compatibility feature and its use is strongly discouraged. You should either prevent the exporting (by saying use POSIX (); , as usual) and then use fully qualified names (e.g. POSIX::SEEK_END ), or give an explicit import list.

Da ich natürlich mehr mache, als ein "paar Greps und viel tamtam", habe ich mir gedacht, ich beisse in meinem Repo in den sauren Apfel und binde POSIX richtig ein - also mit minimalem Namespace Impakt.

Gesagt, use POSIX qw(); getan.

Und siehe da,

$ perl -c hobo.pl
Useless use of string in void context at hobo.pl line 6116.

Tja line 6116 in hobo.pl ist

Code Auswählen Erweitern

    log 1, "copy $fName $root/$restoreDir/$fName failed:$!";

und ich bin mir jetzt relativ sicher, dass man da nicht den Logarithmus berechnen will. Aus der POSIX Doku:

log
This is identical to Perl's builtin log() function, returning the natural (e-based) logarithm of the numerical argument, see log.

Der Witz ist also, dass man nicht nur ein falsches Keyword erwischt hat, man hat eine "einfach mal so importierte" POSIX Funktion erwischt, die sich noch nicht einmal beschwert, wenn das zweite Argument ein String ist. Sobald man das eliminiert, beschwert sich dann der vormals übertünchte Perl log()-builtin.

use warnings; sei dank.

[CoolTux]

Das ist eventuell nur ein Typo.
Sollte bestimmt Log heißen

[herrmannj]

Jo, wobei Richard mit POSIX schon Recht hat. Das sind imho einige hundert Funktionen.

[rudolfkoenig]

Den Tippfehler habe ich behoben.

[RichardCZ]

"nur ein Typo" verkennt die eigentliche Tiefe des Problems. Aber ich bin ja froh maximal zur Qualitätssteigerung beigetragen zu haben.

edit:

mit lediglich

Code Auswählen Erweitern

use POSIX                     qw(getuid setuid
                                 strftime
                                 EAGAIN EINVAL EWOULDBLOCK );

bekomme ich den Server ans Laufen. Und man hat ein use POSIX einmal oben (diese uses mitten im Code sind ja eh die Pest).

Ein grep auf den Source fördert (ganz ohne tamtam) aber gar schröckliches zu Tage: "use POSIX;" soweit das Auge reicht.

[Wzut]

"use POSIX;" soweit das Auge reicht.

Wenn das so verwerflich ist , kann dann mal jemand das Problem in ein Beispiel fassen damit auch ein Kreissklassen Modulautor der eigentlich nur vom abschreiben bei anderen lebt das auch "richtig" umsetzen kann ?

Wie ich es bis jetzt verstanden habe :
1. man wirft in seinem Modulen ersteinmal am Anfang das use POSIX ganz raus.
2. man schaut wo es anschliessend Gemecker gibt, zb. bei

Code Auswählen Erweitern

my $test = hanswilli('blablub');hanswilli ist nun unbekannt, also ersetze ich den Aufruf durch
$test = POSIX::hanswilli('blablub'); ?
3. wenn ich viele solcher Stellen im Modul habe bleibe ich bei der alten Form ersetze aber das einfache use POSIX am Anfang durch use POSIX qw(hanswilli wasauchimmer ); ?   

[Beta-User]

...würde mich auch interessieren, habe grade mal geschaut, ob ich den WeekdayTimer "verbessern" kann (so das denn Sinn macht (?))...

ABER: Soweit mein begrenztes Verständnis reicht, ist das nicht ganz so einfach, weil ja der Namespace gerade nicht irgendwie gekapselt wird. Es reicht doch aus, wenn ein Modul, (das nicht einen eigenen Namespace eröffnet) irgendwo das "allgemeine" use POSIX verwendet (also auch fhem.pl selbst), dann kann man es "überall" verwenden, oder nicht? Aber selbst wenn man es in fhem.pl begrenzen würde: bereits eine myUtils-Datei (entsprechend dem template geschrieben) würde ausreichen, um für alle Module keine Fehlfunktionen beim Aufruf entsprechender Funktionen mehr zu verursachen (?). 
Andererseits: auch der POSIX::-Aufruf setzt voraus, dass das Modul geladen ist (?)...

Und: wären wir andersrum auch davor gefeit, dass plötzlich Module Probleme verursachen, die bisher ohne Mucken liefen, wenn man jetzt POSIX-Funktionen in fhem.pl begrenzt?

Ergo: _Wenn_ es Sinn macht, da was zu tun, und das obige auch nur halbwegs sachlich richtig ist, wird das sehr lange noch "Nachwirkungen" haben, wenn wir das nicht gründlichst machen..., oder?!?

[CoolTux]

Deswegen bin ich ja schon seit Monaten dabei Euch zu bitten mit packages zu arbeiten. Einige Entwickler mit neuen Modulen konnte ich schon dazu anregen.



Grüße

[rudolfkoenig]

mit lediglich ... bekomme ich den Server ans Laufen

Das ist nicht sehr aussagekraeftig, um sicher zu sein muessen alle Module und alle Codeschnipsel in notify/at/DOIF/etc geprueft werden. Ich will damit nicht sagen, dass ich froh ueber "use POSIX" bin, aber ich nehme z.Zt. kein akutes Problem wahr, und bin zuversichtlich konkrete Probleme zu verursachen, wenn ich was aendere.

[Wzut]

Deswegen bin ich ja schon seit Monaten dabei Euch zu bitten mit packages zu arbeiten.

aber da stellt sich doch die gleiche Frage , wie man POSIX einsetzt ?

[RichardCZ]

Wie ich es bis jetzt verstanden habe :
1. man wirft in seinem Modulen ersteinmal am Anfang das use POSIX ganz raus.
2. man schaut wo es anschliessend Gemecker gibt, zb. bei

Code Auswählen Erweitern

my $test = hanswilli('blablub');hanswilli ist nun unbekannt, also ersetze ich den Aufruf durch
$test = POSIX::hanswilli('blablub'); ?
3. wenn ich viele solcher Stellen im Modul habe bleibe ich bei der alten Form ersetze aber das einfache use POSIX am Anfang durch use POSIX qw(hanswilli wasauchimmer ); ?   

Ja, anders habe ich es auch nicht gemacht. Wobei ich dann diese POSIX::xxx eben durch use POSIX qw(xxx) ersetzt habe.
Aber ehrlich gesagt ist da der explizite Aufruf vermutlich sogar noch besser wenn sich die Anzahl der POSIX AUfrufe pro File in Grenzen hält.

@Rudolf: Das übliche "wenn ich was ändere fliegt mir alles um die Ohren" Argument kenne ich ja jetzt, ich stimme sogar (aus eigener Erfahrung) zu, aber das ist ein Korsett, das Dich früher oder später erdrücken wird.  Ich gehe jetzt in meinem Repo den Extremweg: Ultra-progressiv, im Zweifelsfall interessieren mich alte Zöpfe nicht.

Da kann ich mir das erlauben, der einzige Nutzer bin ja wohl ich.

Ich sehe aber schon relativ deutlich (und hatte eigentlich die Hoffnung Du auch), dass ich auf diesem Weg Probleme aufdecke, die "euch" verborgen bleiben. Und so ist es doch auch. Diese

"so lange es kein aktues Problem gibt"
"ist nur ein Typo"

Aussagen sind - sorry - Selbstbetrug. FHEM hat akute Probleme, nur will man das nicht sehen.

"Ach deswegen habe ich so unerklärliches Verhalten..." (HMCCU min/max)

Im Grunde genommen habe ich den Eindruck, man sagt "So lange der Server läuft ist nix akut".
Wenn ich dann sage "Mein Server läuft", dann heißt es aber plötzlich "das sagt noch lange nix". Ist doch Schizo. 

[rudolfkoenig]

...der main Namespace in FHEM ja ziemlich überfüllt ist...

Ich habe keine belastbare Ursachenstatisktiken parat, aber in den 13 Jahren Support fuer FHEM erinnere ich mich an genau ein Problem, dessen Ursache namespace-collision war, und das Problem hat weniger als eine Stunde Aufwand fuer alle zusammen gekostet.

Und über die daraus resultierende grenzwertige Wartbarkeit...

Da ich davon ausgehe, dass deine Erfahrung mit FHEM-Support begrenzter ist, halte ich diese Aussage fuer polemisch.

Ich will damit nicht sagen, dass ich keine Probleme behebe, aber Aufwand/Nutzen muss im Rahmen bleiben. Ich kenne das Gefuehl, einen grossen, nicht selbstgebauten Software vor sich zu haben, und alles besser machen zu wollen, weil man gute Gruende dafuer hat. Aber ich kann inzwischen die Position der anderen Seite verstehen.

[Wzut]

Wenn man hier ne Weile dabei ist und schon so manchen Teufelskreis live miterlebt hat kann ich Rudis Haltung gut nachvollziehen.
( Ich habe selbst Schiss meine MAX Beta Module via commit auf alle lozulassen )
@RichardCZ, ist es nicht einfacher statt von oben nach unten das Problem von unten nach oben anzugehen ?
Sprich zuerst kommen die Modulautoren, die kennen ihre Module und können i.d.R. auch sehr gut testen ( z.B. weil die Hardware vorhanden ist )
   

[RichardCZ]

Ich habe keine belastbare Ursachenstatisktiken parat, aber in den 13 Jahren Support fuer FHEM erinnere ich mich an genau ein Problem, dessen Ursache namespace-collision war, und das Problem hat weniger als eine Stunde Aufwand fuer alle zusammen gekostet.

Das ist interessant, denn in den letzten 7 Tagen habe ich 2 NS-collisions aufgezeigt. (min/max & log). Ob man die nun "typo" oder "hach ich dachte das ist was anderes" nennt ist egal.

Da ich davon ausgehe, dass deine Erfahrung mit FHEM-Support begrenzter ist, halte ich diese Aussage fuer polemisch.

Meine Erfahrung mit FHEM Support ist nicht vorhanden. Es ist jetzt aber nicht so, dass ich keine Erfahrung mit Systemen hätte die eine breite Installationsbasis in der Produktion haben. Überleg' Dir mal was es für eine Linux Distribution bedeutet wenn "plötzlich" 500 000 Leute updaten.

Hunderte neuere Versionen von Applikationen, Readmes, etc. Hobbyanwender klopfen das irgendwie hin, "Profi-Umgebungen" haben ihre Admins
die sich vorab informieren, testen und kümmern.

* Development: stable (release tag) und progressive (trunk) branches, für die ganz wilden Cowboys auch mal ne experimental-branch
* Deployment: /opt/fhem

$ ll
total 16
drwxr-xr-x 2 fhem fhem 4096 Mar 24 09:54 6.0
drwxr-xr-x 2 fhem fhem 4096 Mar 24 09:54 7.1
lrwxrwxrwx 1 fhem fhem    3 Mar 24 09:55 active -> 7.1
drwxr-xr-x 2 fhem fhem 4096 Mar 24 09:54 r25744
drwxr-xr-x 2 fhem fhem 4096 Mar 24 09:54 r27833


/opt/fhem/active wäre das neue Zuhause, bei Bedarf schaltet man mal um, sieht was einem im Xicht explodiert und schaltet wieder zurück.
Ach so, vielleicht geht das in Windows nicht/anders. Nicht mein Problem. 

Ne - ehrlich, ist denn irgendwo definiert was man sich alles "antun will"? Ich lese "bei all den OS, Perl, MOdul"-Kombinationen. Nirgends habe ich gelesen was so die älteste Perl Version ist die man "unterstützt". 5.8.x? 5.6? Srsly?

[betateilchen]

so langsam nervt mich diese Klugscheißerei...