[patch] Vorschlag: Durchgängige Verwendung von %L in der Standardauslieferung

[betateilchen]

Da aktuell mehrere Diskussionen zum Theme "ich möchte meine Logfiles woanders haben, wie mache ich das am einfachsten" geführt werden, schlage ich vor, in der Standardauslieferung von fhem grundsätzlich keine festen Pfade mehr vorzugeben, sondern konsequent mit %L zu arbeiten. Das würde den Anwendern späteres Verschieben des log-Verzeichnisses enorm erleichtern.

Soweit ich das überblicke, bedarf es dazu Änderungen in den Dateien

• fhem.cfg
• fhem.pl (um das Wildcard auch im Statefile Attribut auszuwerten)
• 91_eventTypes.pm

eventTypes wertet bereits heute %L korrekt aus. Allerdings fehlt dort ein Internal, in dem der tatsächliche Dateiname steht. Dieses Internal ist erforderlich, um den automatischen korrekten Dateiimport bei einer Migration fhem.cfg nach configDB sicherzustellen.

Bei autocreate blicke ich beim automatischen Anlegen der FileLog Definitionen noch nicht so ganz durch - da bräuchte ich etwas Unterstützung.

Code Auswählen Erweitern


Index: fhem.cfg
===================================================================
--- fhem.cfg (Revision 11753)
+++ fhem.cfg (Arbeitskopie)
@@ -1,6 +1,7 @@
-attr global logfile ./log/fhem-%Y-%m.log
+attr global logdir ./log
+attr global logfile %L/fhem-%Y-%m.log
attr global modpath .
-attr global statefile ./log/fhem.save
+attr global statefile %L/fhem.save
attr global verbose 3
attr global updateInBackground

@@ -15,12 +16,12 @@
attr WEBtablet stylesheetPrefix touchpad

# Fake FileLog entry, to access the fhem log from FHEMWEB
-define Logfile FileLog ./log/fhem-%Y-%m.log fakelog
+define Logfile FileLog %L/fhem-%Y-%m.log fakelog

define autocreate autocreate
-attr autocreate filelog ./log/%NAME-%Y.log
+attr autocreate filelog %L/%NAME-%Y.log

-define eventTypes eventTypes ./log/eventTypes.txt
+define eventTypes eventTypes %L/eventTypes.txt

# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create


Code Auswählen Erweitern


Index: fhem.pl
===================================================================
--- fhem.pl (Revision 11753)
+++ fhem.pl (Arbeitskopie)
@@ -1347,9 +1347,14 @@
     return cfgDB_SaveState();
   }

-  return "No statefile specified" if(!$attr{global}{statefile});
-  if(!open(SFH, ">$attr{global}{statefile}")) {
-    my $msg = "WriteStateFile: Cannot open $attr{global}{statefile}: $!";
+  my $stateFile = AttrVal('global','statefile',undef);
+  return "No statefile specified" unless defined($stateFile);
+
+  my @t = localtime;
+  $stateFile = ResolveDateWildcards($stateFile, @t);
+
+  if(!open(SFH, ">$stateFile")) {
+    my $msg = "WriteStateFile: Cannot open $stateFile: $!";
     Log 1, $msg;
     return $msg;
   }


Code Auswählen Erweitern


Index: 91_eventTypes.pm
===================================================================
--- 91_eventTypes.pm (Revision 11753)
+++ 91_eventTypes.pm (Arbeitskopie)
@@ -77,6 +77,7 @@
   my $cnt = 0;
   my @t = localtime;
   my $f = ResolveDateWildcards($a[2], @t);
+  $hash->{eventTypesFile} = $f;

   my ($err, @content) = FileRead($f);
   my (%h1, %h2);


[Markus Bloch]

Warum nicht gleich %L weglassen und das globale Attribut "logdir" als Base-Dir für Logfiles global setzen, so dass man relative Pfade ausgehend von logdir in FileLog/eventTypes/stateFile/... angibt?

Code Auswählen Erweitern


attr global logdir ./log
attr global logfile fhem-%Y-%m.log

# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog fhem-%Y-%m.log fakelog

define autocreate autocreate
attr autocreate filelog %NAME-%Y.log

define eventTypes eventTypes eventTypes.txt


Ich habe das jetzt nicht geprüft, ob das umsetzbar ist und wie man es lösen könnte. Die Idee kam mir nur direkt beim lesen Deines Beitrags.

Gruß
Markus

[betateilchen]

Hallo Markus,

das hatte ich auch überlegt, das bedarf aber erheblich mehr patches. Letztlich ging es mir nur darum, die Stellen anzufassen, wo es bisher noch nicht durchgängig funktioniert.

Ausserdem werden die Wildcards ohnehin schon in der fhem.pl aufgelöst, da ist %L eben nur ein Eintrag von vielen und der Mechanismus funktioniert grundsätzlich. Hat sich ja bisher auch gut bewährt, es ist eben nur nicht überall konsequent umgesetzt.



Edit: ausserdem wäre Dein Vorschlag nicht rückwärtskompatibel, weil er in allen Installationen, in denen jetzt schon mit %L gearbeitet wird, Fehler produzieren würde.

[rudolfkoenig]

Insgesamt sehe ich %L bzw logdir problematisch, deswegen bin ich erstmal dagegen, es zu propagieren.
- es stammt nicht von mir, auch wenn es seit lange eingefuehrt ist, es ist auch nur versteckt dokumentiert. Stammt aus der Zeit, wo ich noch nicht auf dem "relativen Trip" mit ./log war.
- es ist nicht intuitiv verstaendlich, was mit %L gemeint ist. Doku lesen ist nicht die Staerke der Anwender. Wenn wir es einfuehren, muesste es deutlich prominenter dokumentiert werden. Insgesamt kompliziert logdir unnoetig die Sachen.
- Benutzer werden erwarten, dass wenn man logdir in FHEMWEB aendert, die Dateien automatisch rueberwandern.
- Verfuehrt zur Verwendung von absoluten Pfaden, was laengerfristig nervt (z.Bsp. mich im Support).
- man kann auch jetzt ./log einfach per Symlink umbiegen, oder ./log in fhem.cfg ersetzen.

@betateilchen: du hast aber insofern recht, dass es konsequent waere %L auch in fhem.save zu verwenden.

[betateilchen]

Ich sehe nicht, wo der Unterschied ist, dem Benutzer zu erklären, was %L bedeutet, wenn vorausgesetzt wird, dass er versteht, was %Y bedeutet. Zu erklären, dass mit einer Änderung an logdir nicht automatisch bestehende Dateien verschoben werden, sehe ich auch nicht unmöglich.

Eigentlich bilden logdir und %L ein tolles Feature von fhem, das schon lange existiert, aber leider viel zu wenig beachtet wird.

- man kann auch jetzt ./log einfach per Symlink umbiegen, oder ./log in fhem.cfg ersetzen.

Wenn es denn im System überhaupt eine fhem.cfg gibt. Aber auch durch das Ersetzen des Pfades in der Konfigurationsdatei werden noch lange keine bestehenden logs irgendwohin verschoben. Und Symlinks sind auch nicht unbedingt eine Stärke der Anwender.

[herrmannj]

Ich unterstütze Betateilchens Vorschlag sehr.

So versteckt ist das auch nicht dokumentiert. Aus eigener Erfahrung: ich habe vor Jahren versucht das zu verwenden (lt Doku) und war dann verunsichert weil es eben nicht, so wie dokumentiert, gearbeitet hat.

vg
joerg

[rudolfkoenig]

Ich habe die %L Unterstuetzung fuer statefile eingebaut (Patch von betateilchen fuers Schreiben, plus die andere Haelfte, damit es beim Einlesen auch funktoniert).

war dann verunsichert weil es eben nicht, so wie dokumentiert, gearbeitet hat.

Das haette ich gerne genauer. %L ist nur fuer FileLog dokumentiert, und da sollte es auch funktionieren.

[betateilchen]

Über die Art (den Text) wie das in der commandref beschrieben ist, bin ich anfangs auch gestolpert. Aber nachdem ich dann kapiert hatte, wie simpel der Gedanke dahinter ist, hat es auch klaglos funktioniert - und tut das hier nun schon sehr lange.

Muss mir den Text nochmal anschauen, vielleicht fällt mir etwas ein, wie man es einfacher erklären kann

[betateilchen]

Das haette ich gerne genauer. %L ist nur fuer FileLog dokumentiert, und da sollte es auch funktionieren.

Das Attribut nrarchive funktioniert nicht, wenn logdir gesetzt ist und %L verwendet wird.

Das Problem liegt vermutlich (in fhem.pl) in HandleArchiving($;$) aber ich hatte noch keine Zeit, der Sache nachzugehen, da ich im logdir ohnehin auf Linux-Ebene mit logrotate arbeite.

[herrmannj]

Ich habe die ganze Zeit überlegt was es war. Ist echt schon ne Weile her. Mach das jetzt seit langem via symlink, + var/log.

Danke!!

vg
joerg

[rudolfkoenig]

Das Attribut nrarchive funktioniert nicht, wenn logdir gesetzt ist und %L verwendet wird.

Das habe ich jetzt gefixt.

[betateilchen]

Und dann gibt es noch fhem-Module, die irgendwie ein FileLog anlegen, selbst wenn man überhaupt kein autocreate-device hat und die dann wieder hart ./log in die FileLog-DEF schreiben, egal was man global in logdir definiert hat.

Wenn es nun in einer fhem-Installation den Pfad ./log aber nicht gibt und fhem tatsächlich versucht, in diesen Pfad zu schreiben ... *grmpf*

[herrmannj]

Naja, aber denen muss man halt den Spiegel vorhalten. Ist ja kein fhem core Thema. Bei den modulen ist dann leider die qualität unterschiiedlich, siehe die ganzen synchronen calls.

vg
joerg