#928 Issue closed: implement ternary config variables

Labels: won't fix / can't fix / obsolete

jsmeix opened issue at 2016-07-18 11:58:

Currently rear does not support ternary config variables
in general.

With ternary config variables I mean in particular
boolean config variables that can have a third valid vaule
which is "undefined".

With ternary boolean config variables
(intentionally the wording looks self-conradicting ;-)
it is possible to distinguish a default/fallback setting
from an explicitly wanted setting by the user.

The default is used when the config variable is "undefined".
When the config variable is "true" or "false" it means an
explicitly wanted setting by the user.

This means the default behaviour must be implemented
as a fallback when no specific behaviour is defined.

But it is not needed to change zillions of places in the code
to do that.

Actually it is sufficient to only implement setting the
config variables this way, i.e. setting the default value
of the config variables as a fallback when no specific
value is defined by the user.

Currently usr/share/rear/conf/default.conf is read
in usr/sbin/rear at the very beginning, in particular
it is read before the user's settings in etc/rear/local.conf

Hereby I propose to do that the other way round:

First read etc/rear/local.conf to know what config variables
have an explicitly wanted setting by the user.

Then do in usr/share/rear/conf/default.conf
for boolean variables something like

is_true $VAR || is_false $VAR || VAR=default_value

and for non-boolean variables something like

test "$VAR" || VAR=default_value

Basically before user settings did overwrite defaults
now defaults are only set if not specified by the user.

What do you think?

schlomo commented at 2016-07-18 16:05:

Can you please provide a specific example of a use case where we would
achieve a major improvement with such a change?

Am 18.07.2016 1:58 nachm. schrieb "Johannes Meixner" <
notifications@github.com>:

Currently rear does not support ternary config variables
in general.

With ternary config variables I mean in particular
boolean config variables that can have a third valid vaule
which is "undefined".

With ternary boolean config variables
(intentionally the wording looks self-conradicting ;-)
it is possible to distinguish a default/fallback setting
from an explicitly wanted setting by the user.

The default is used when the config variable is "undefined".
When the config variable is "true" or "false" it means an
explicitly wanted setting by the user.

This means the default behaviour must be implemented
as a fallback when no specific behaviour is defined.

But it is not needed to change zillions of places in the code
to do that.

Actually it is sufficient to only implement setting the
config variables this way, i.e. setting the default value
of the config variables as a fallback when no specific
value is defined by the user.

Currently usr/share/rear/conf/default.conf is read
in usr/sbin/rear at the very beginning, in particular
it is read before the user's settings in etc/rear/local.conf

Hereby I propose to do that the other way round:

First read etc/rear/local.conf to know what config variables
have an explicitly wanted setting by the user.

Then do in usr/share/rear/conf/default.conf
for boolean variables something like

is_true $VAR || is_false $VAR || VAR=default_value

and for non-boolean variables something like

test "$VAR" || VAR=default_value

What do you think?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/rear/rear/issues/928, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGMCGZpOiHFlW3ow3o9o6kD21yow1tzks5qW2pdgaJpZM4JOpJ4
.

jsmeix commented at 2016-07-19 08:36:

In short: Forget it (it does not work).

The wish was the father of the thought.

Last weekend I had that idea because I thought
it could help me to escape from the old problem
to find out if a setting is actually intended by the user
or if it is just the default.

As usual, a short time after I posted it,
it crept into my mind that "my great idea"
actually does not at all help.

The result is the same for both kind of implementations:
First set defauts then overwrite what is set by the user
or
first do user settings then set defaults for the rest.

But the first implementation is simpler.
Therefore "my great idea" would only make
the implementation more complicated.

The reasons why it does not help to solve the
original problem are:

Regardless how a value was set,
later it is imposible to find out if the value was set
explicitly by the user or by a default setting.

Assume the default setting is VAR="this"
and "this" is what the user wants to have,
then the default "just works" for the user
so that he will not explicity specify VAR="this"
and there is no way how to find out that the
user explicitly wants to have "this".
(When later the default changes to VAR="that"
it suddenly does no longer work for that user.)

[Export of Github issue for rear/rear.]