Sometimes in a situation like this it works well if the individually-called scripts are “stub” routines that use a common package, perhaps employing the contents of that package as an object (because, when you do so, you now have lumped code-and-data conveniently together).

The idea here is that, even though you have several scripts being called by your command-files or what not, all of the related code is actually in one place and not repeated.

I like to define subroutines (or properties, as the case may be...) so that there is no “just one right-way to call it.”   In other words, I would instantiate the object and give it a method that “magically” returns the IP on-request.   When you call it (because that is what you want to know), the code does whatever it has to do at that time ... or else it realizes that it can’t do so and it dies with a meaningful message.   I don’t like to see routines that, “well, they work properly, if you have done this-and-that first, otherwise it does weird things.”   (I call the latter “genie in a bottle” routines, from the very bad pop song that was around a few years ago:   “... you gotta rub me the right way.”)