I have a large configuration script (bash) that is pretty well modularized into separate functions to complete a bunch of tasks for installing/configuring a new rollout of a software suite.
We have realized that it would be very useful to have some of these functions available to be called without executing the entire script. I could have made the script accept an argument to call the specific function, but because the script has grown to well over 1200 lines already, for readability I intend to split it into sub-scripts that will execute from the parent. The goal is that the sub-scripts could execute independently to re-configure something specific.
The parent script (call it the wizard) in its original form, had several global variables that were manipulated by the functions as the script ran. In order for the script to be split, I'm creating a persistent file for all the config values, along with a function that allows functions to update the key=value pairs in the persist file (or adds them, if they don't already exist).
Ok, so the actual question! Since the wizard is the parent script, and the children (sub-scripts) can edit or add config values when they are called, is it acceptable for the wizard to re-source the persist file multiple times through the wizard's flow (which is necessary since sourcing doesn't flow "upwards")? I.e.- any time a wizard function starts that configures a certain piece of software, it sources the file first in case a sub-script made a change to a config value.
Since the functions are sourcing the file, I'm assuming that once the function is complete, it goes out of scope (or whatever the equivalent terminology is in bash). So this shouldn't cause issues, but I'd love to be sure. Thanks for any advice!
**EDIT: For clarification, the main reason for using the persist file (and why I call it that) is that I want it to stay available for when one of the sub-scripts are called on an individual basis. Without the wizard setting up the global variables, they would be missing vital information about their environments when run standalone.