"include" does not work as expected

[andim]

Hi,

unable to post in Development forum (possibly limited to very active developers?),thus adding blurb here:

Since I had recurring issues with fhem config files getting destructively overwritten, I had decided to move my important content into separate .cfg:s, to be included from a main fhem.cfg (so that that included content will eventually end up overwriting the pseudo main fhem.cfg rather an actually important main fhem.cfg file).

This, unfortunately, does not work in a satisfactory way.

# perl fhem.pl fhem.cfg
2014.01.08 22:12:28 1: Including fhem.cfg
2014.01.08 22:12:28 1: Including /opt/fhem/fhem.cfg.demo
Use of uninitialized value $modpath in concatenation (.) or string at fhem.pl line 1753, <> line 4.

Simple way to reproduce it:
cd /opt/fhem

fhem.cfg:
include /opt/fhem/fhem.cfg.demo

perl fhem.pl fhem.cfg

So, obviously, modpath will be defined by the to-be-included file, yet *prior* to processing of the first include statement for some reason fhem already seems to require a valid modpath definition. Ugh.


What's worse, the simple step of moving fhem.cfg.demo one level down via a simple "include" by a dummy fhem.cfg will end up with the line
    perl fhem.pl fhem.cfg
then NOT successfully forking into background (possibly since it is unable to enter main loop, or some such).

Any ideas how to improve the modpath definition lifetime/access issue? And about the backgrounding issue?

Debian package fhem 5.5, on OpenWrt Debian extroot TL-WDR3600 mips.

Thanks!

[ph1959de]

Only from my own experience (not being a Fhem-developer): there is a - obviously not completely documented - set of instructions that needs to stay in the "startup"-configuration file, i.e. the .cfg you specify on the fhem start command. I think, most of the "attr global" definitions belong to the statements that should not be moved elsewhere.

Besides that, I did not recently experience any issues with moving definitions (devices, notify, at, etc.) into included configuration files.

You need, however, to keep in mind, that autocreate/autosave stuff will always end up in the startup .cfg.

Btw: is there any special reason for letting your own configuration files end on something else than .cfg? I for my part have named all includes along the pattern of myIncludeFileName.cfg (searching for definitions is a simple "grep searchtext *.cfg" then).

I recently wrote down what I learned about Fhem's configuration in the wiki page http://www.fhemwiki.dewiki/Konfiguration (in German "only"). I can't deny, that that information needs to be extended / completed.

And, finally, yes, saving / backing up the configuration files frequently and regularly is a good idea.

Peter