Save and restore bash flags and options settings #724
Conversation
functionality for bash flags and options settings, see rear#700
in usr/share/rear/lib/framework-functions.sh which should obsolete the DEBUGSCRIPTS_OPPOSITE_ARGUMENT workaround, see rear#700
and ApplyBashFlagsAndOptionsCommands that are used
in a fail-safe way via an explicit variable that
stores the current bash flags and options commands
and using that explicit variable to re-apply them, i.e. like
saved_flags_options_cmds="$( GetBashFlagsAndOptionsCommands )"
... [change bash flags and options]
... [do something]
ApplyBashFlagsAndOptionsCommands "$saved_flags_options_cmds"
In contrast using implicitly a stack of saved_flags_options_cmds
via SaveFlagsAndOptions and RestoreFlagsAndOptions functions
is not equally fail-safe because one must carefully ensure that
each element that is put onto the stack via SaveFlagsAndOptions
gets removed later via RestoreFlagsAndOptions, e.g.
SaveFlagsAndOptions
... [change bash flags and options]
... [do something]
if <condition> ; then
SaveFlagsAndOptions
... [change bash flags and options]
... [do something]
fi
... [do something]
RestoreFlagsAndOptions
restores wrong flags and options in case of <condition>.
Furthermore using implicitly a stack of saved_flags_options_cmds
makes it complicated to restore an explicity named state
or to simply restore a specific state several times like:
initial_flags_options_cmds="$( GetBashFlagsAndOptionsCommands )"
... [change bash flags and options]
... [do something]
if <condition> ; then
saved_flags_options_cmds="$( GetBashFlagsAndOptionsCommands )"
... [change bash flags and options]
... [do something]
ApplyBashFlagsAndOptionsCommands "$saved_flags_options_cmds"
... [do something]
fi
ApplyBashFlagsAndOptionsCommands "$initial_flags_options_cmds"
... [do something]
... [change bash flags and options]
... [do something]
ApplyBashFlagsAndOptionsCommands "$initial_flags_options_cmds"
|
Oops! This pull request has documentation stuff from my other pull request mixed in. I will close this broken pull request. |
|
Cool. Can you please use More consistent with the remaining ReaR code. |
|
Oops2! I used function names as in _input-output-functions.sh Function names are lower case, words separated by underline (_) Now I wonder if - and if yes - how to distinguish function names Globally used variables are uppercase (with words separated by underline '_') like SHARE_DIR DISKLAYOUT_FILE RECOVERY_FS_ROOT Locally used varaiables should be lowercase and marked with "local" (also words separated by underline '_') like "local backup_path" or "local syslinux_modules_dir". I think distinguishing functions from variables is obvious from the context how they are used so that both can have same syntax. I wonder if we should distinguish globally used functions from locally used functions by their naming syntax? E.g. leading capitals for words in globally used functions like function Globally_Used_Function () {
...
}
in contrast to function locally_used_function () {
...
}
.
.
.
locally_used_function ...
.
.
.
unset -f locally_used_function
|
|
Do we actually have a problem here? I would like to keep the rules to the absolue minimum... |
|
I do not have a problem. I was only wondering and therefore I asked. In #726 I use the function names get_bash_flags_and_options_commands and apply_bash_flags_and_options_commands |
Implemented simple functions GetBashFlagsAndOptionsCommands
and ApplyBashFlagsAndOptionsCommands that are used
in a fail-safe way via an explicit variable that stores the
current bash flags and options commands and using
that explicit variable to re-apply them, i.e. like
saved_flags_options_cmds="$( GetBashFlagsAndOptionsCommands )" ... [change bash flags and options] ... [do something] ApplyBashFlagsAndOptionsCommands "$saved_flags_options_cmds"See #700