Add configuration file support for unattended mod sensors installation

[eremem]

When placed in the script's directory, a configuration file named pve-mod-gui-sensors.settings allows for an unattended installation. A sample configuration file is included, containing supported settings that emulate user choices. By default, no predefined choices are available, so the existence of the file alone does not enable unattended mode.

Fixes #115

[Meliox]

Nice. Would it be worth waiting until version 2.0 is ready? There is a whole range of config settings, that may or may not be exposed? https://github.com/Meliox/PVE-mods/pull/152/changes#diff-3c7350fe283730d5c07a73b3b0286e132a25645f9412e816c71666dcd7450effR41
Can they be easily included in this design?

Also, this would also allow us to use hooks :)

1. Create an APT hook
nano /etc/apt/apt.conf.d/99-pve-hooks

2. Add this content
DPkg::Post-Invoke {
    "if dpkg -l | grep -E '^ii  (pve-manager|pveproxy)' >/tmp/pve_pkg_check; then \
        /usr/local/bin/pve-post-update.sh; \
    fi";
};

3. Create your script
nano /usr/local/bin/pve-post-update.sh
chmod +x /usr/local/bin/pve-post-update.sh

[eremem]

Nice. Would it be worth waiting until version 2.0 is ready? There is a whole range of config settings, that may or may not be exposed?

Since the settings are global variables, the new settings can be easily added to the config file and then you need the evaluation of them in the script.

https://github.com/Meliox/PVE-mods/pull/152/changes#diff-3c7350fe283730d5c07a73b3b0286e132a25645f9412e816c71666dcd7450effR41

The settings are primarily intended to emulate the user's answers to the ask() calls. However, they are not limited to this use-case, and you could also add some 'indirect' settings.
I don’t see any ask() calls in the diff above, so we could also start with the current settings in v2 without any functionality loss.

TBH, I see no particular reason to wait until v2. Do you?

[Meliox]

Ok, no, then not really.

if [ -n "$CONFIG_UPS_CONNECTION" ]; then
	upsConnection=$CONFIG_UPS_CONNECTION
else
             upsConnection=$(ask "Enter UPS connection (e.g., upsname[@hostname[:port]])")
fi

Could the asks be made as a generic function that could be used throughout with appropiate parameters to simplify code.

[eremem]

Ok, no, then not really.

if [ -n "$CONFIG_UPS_CONNECTION" ]; then
	upsConnection=$CONFIG_UPS_CONNECTION
else
             upsConnection=$(ask "Enter UPS connection (e.g., upsname[@hostname[:port]])")
fi

Could the asks be made as a generic function that could be used throughout with appropiate parameters to simplify code.

If my memory serves it is already as generic as it's possible with bash. There is e.g. no support for passing parameters to functions by reference, so you need the return value assignment.

What use-case do you have in mind? Could you give me some example how you would like to use/call ask() ?

[Meliox]

No use case, really apart from eliminating some code redundancy. What about when loading the config, set the variables directly in the load and then if empty, then ask.

[eremem]

It sounds reasonable. I'll check if the name of a configuration variable can be passed as a second parameter, and if its value is not empty, it will be returned as the function's result.