#1408 PR merged: Automated unique default user_input_ID for UserInput¶
Labels: enhancement, fixed / solved / done
jsmeix opened issue at 2017-07-13 14:26:¶
Have an automated unique default user_input_ID
for the UserInput function so that each
UserInput function call has a user_input_ID
which is some kind of precondition for
https://github.com/rear/rear/issues/1366
Now (at least from my current point of view)
the UserInput function should be feature-complete.
It needs 'bc' to calculate huge numbers and (fortunately) since
https://github.com/rear/rear/pull/1332
'bc' is one of the REQUIRED_PROGS in default.conf
so that it is also available in the ReaR recovery system.
By the way I enhanced the CallerSource function
that now also outputs the line number (useful in bigger scripts)
because I learned how to use BASH_LINENO correctly
(there is an unexpected - but documented - "off by one"
for the BASH_LINENO array index).
schlomo commented at 2017-08-25 06:53:¶
@jsmeix I had another close look at the UserInput function and I am
not sure if the automatically generated hash numbers will be useful or
harmful. The reason is that they change if the call is moved to another
script or even if we change a single letter in the wording. If
somebody where to create responses for a specific ReaR run and we move
that input query to another script or just fix the wording then his
responses won't work anymore. That means that every such change -
regardless how minor - would be a breaking change for the user.
I therefore would like us to consider to remove this automatic feature
with the goal of only having explicit interfaces for users to configure
and not to have implicit interfaces. As we just introduce the
UserInput function I think that it is much easier for all of us
maintainers and also for our users if we simply assign those numbers
manuall. At the moment there are only very few uses of the function
that we would have to extend with the number (starting from 1) and then
we simply count up as we add more UserInput calls. If you want we can
make assigning the number a mandatory argument to force everybody to set
one.
People will still have to update their answers when we change the wording of the answer they use but at least they won't have to do anything when we move the code or when we change the default or an answer that they didn't care about.
Here is the list of files to update, IMHO no big deal:
$ git grep -cE '^[^\#]+\(\s*UserInput'
usr/share/rear/format/USB/default/200_check_usb_layout.sh:1
usr/share/rear/format/USB/default/300_format_usb_disk.sh:1
usr/share/rear/layout/prepare/GNU/Linux/150_include_drbd_code.sh:1
usr/share/rear/layout/prepare/default/600_show_unprocessed.sh:1
usr/share/rear/restore/BORG/default/300_load_archives.sh:1
usr/share/rear/restore/FDRUPSTREAM/default/270_selinux_considerations.sh:1
usr/share/rear/restore/NBKDC/default/400_restore_backup.sh:1
What do you think?
jsmeix commented at 2017-08-25 12:57:¶
@schlomo
of course I know how the automated IDs change
(I made the code and the comments ;-)
The idea is that each different UserInput function is called
with its own ID explicitly specified in the call like
UserInput -I 123 ...
The automated default user_input_ID is only there
as fallback for UserInput function calls without '-I'
so that the user can in any case provide predefined
automated input even if a UserInput function is called
without '-I'.
Why I currently do not call UserInput with '-I':
Because IDs of different UserInput function calls
must be different and currently I have no good idea
for a reasonable and meaningful numbering scheme.
I think the ID should contain the script number,
e.g. in 123_do_something.sh it should be
UserInput -I 123... ...
but the script number is not unique so that
I need more...
As soon as I have a good idea for a reasonable and
meaningful numbering scheme I will add '-I ...'
to all UserInput calls.
jsmeix commented at 2017-08-25 13:06:¶
Note that UserInput calls can even have same IDs
when those calls have same purpose.
Only a theoretical example (I don't know a real one):
E.g. in various backup restore scripts
for various backup methods there could be
same UserInput calls that have same purpose.
Like for backup methods where ReaR basically only
pauses until the admin had restored it manually like
UserInput -I 999999 -t 0 -p 'Press [Enter] to continue after restore'
Of course this here is only a theoretical example
because in this case automated user input
is clearly never ever wanted.
schlomo commented at 2017-08-25 13:46:¶
I fully understand and share your concerns, @jsmeix
The more we talk about this the more I get the feeling that a bash array is the wrong tool for providing the answers to ReaR questions. Bash arrays are indexed by numbers which is apparently not flexible enough.
How about switching to property files? Let's think about a directory
/etc/rear/answers where users can place files named like
foobar.property that contain answer like that:
network.use-network-card=0
storage.use-disk.sda=0
storage.multipath.failed-loading=0
And of course the user input function for the multipathing issue we
discuss in #1449 would be called with
-I storage.multipath.failed-loading to make it read that answer.
The idea is semantic naming for the user input ID. With a little magic grep and sed I will be able to create for you an answer file where everything is commented out :-)
With such a model (string instead of number as user input ID) you don't need to keep a precise inventory of existing user input IDs.
And I would still prefer to not have automatic user input IDs because I don't want to create an interface that will change as we refactor ReaR code.
jsmeix commented at 2017-08-25 15:45:¶
Only a side note
that is related to
https://github.com/rear/rear/issues/1390
Bash 4.x supports associative arrays where the members
are referenced using arbitrary strings,
e.g. on my SLES12
(the 'declare -A' is mandatory)
# unset USER_INPUT_VALUES
# declare -A USER_INPUT_VALUES
# USER_INPUT_VALUES[first_user_input]='input for UserInput -I first_user_input'
# USER_INPUT_VALUES[second_user_input]='input for UserInput -I second_user_input'
# USER_INPUT_VALUES[third_user_input]='input for UserInput -I third_user_input'
# for user_input in "${USER_INPUT_VALUES[@]}" ; do echo "'$user_input'" ; done
'input for UserInput -I second_user_input'
'input for UserInput -I third_user_input'
'input for UserInput -I first_user_input'
# index='second_user_input' ; echo ${USER_INPUT_VALUES[$index]}
input for UserInput -I second_user_input
# USER_INPUT_VALUES[last user input]="input for UserInput -I 'last user input'"
# for user_input in "${USER_INPUT_VALUES[@]}" ; do echo "'$user_input'" ; done
'input for UserInput -I second_user_input'
'input for UserInput -I 'last user input''
'input for UserInput -I third_user_input'
'input for UserInput -I first_user_input'
# index='last user input' ; echo ${USER_INPUT_VALUES[$index]}
input for UserInput -I 'last user input'
jsmeix commented at 2017-08-25 15:52:¶
If we do not have automatic user input IDs
it is still mandatory for me that the user can
always predefine an input for any UserInput call
which means then a UserInput call must be with '-I'
otherwise the UserInput function aborts with BugError.
I think with strings as ID this should be acceptable
so that even the user can ad-hoc add an UserInput call
in any of the scripts because with strings as ID the
user could simply use any dummy ID
e.g. to pause somewhere in a script
with something like
UserInput -I asdfghjkl -t 0 -p 'Press [Enter] to continue'
when he does not care about the ID string.
jsmeix commented at 2017-08-25 16:04:¶
@schlomo
why a directory like /etc/rear/answers?
I think a single file /etc/rear/user_input[.conf]
that contains lines of bash syntax (as anything in ReaR)
with string variable assignments like
ID_string="arbitrary user input string"
should be sufficient.
I would like to source that file in the UserInput function
but I wonder how to ensure that those assinged variables
are kept local inside the UserInput function so that
no other ReaR variables could be accidentally overwritten?
schlomo commented at 2017-08-26 20:08:¶
Whatever we do must support multiple configuration / input files so that people can easily provide different answers from different sources (e.g. packages). Therefore I'd like to have a directory where users can put multiple files.
Personally I think that editing a properties file is simpler because
there you have the user input ID as the key without any prefix. But I
don't insist on that. What I do find important is that the user input ID
is something that the user can set "as is" in a file. If the user input
IDs are Bash variables then we must prefix them with some constant and
then the UserInput function should also be called with that prefixed
ID and output that prefixed ID in the debug log etc.
So the main question is probably: Do we want to have user input IDs
without a prefix? Then we should put them into a different configuration
namespace which would be a different configuration directory. Even if
the format is Bash (and we read it with source), we would need that
different directory to avoid the constant prefix for each and every key.
And I am not sure if ID_ is enough of a prefix or if it is
sufficiently self explanatory. Maybe ANSWER_ will be easier to
understand.
[Export of Github issue for rear/rear.]