Is it correct that there are two ways to reuse a script A in another script B:
script B invokes script A as a command (B creates a child process to run A)
I was wondering when to use which way?
Even in cases where both can work, which one is preferred over which for what reasons?
Thanks.
Both ways are valid, but very different.
By using script A in script B (calling it as a command), you leave the possibility of using script A separately for doing whatever it is that script A is doing without script B.
By moving the operational parts of script A into functions, you turn it into a library of sorts. Script A then does not do anything by itself, other than defining a number of functions, and another script would have to source it and use the functions itself.
Both approaches are perfectly valid, and neither is very uncommon. Which one to use totally depends on what script A is originally doing, if it needs to continue doing that (in which case turning it into a library would not be possible1) and whether more scripts than script B might benefit from the functions that script A-as-a-library would provide.
A third possibility would obviously be to put all the common bits from script A and B into functions in a script C, which then would function as a library of functions that the other two makes use of by first sourcing it. In the extreme case, this may well leave one or both of A and B almost empty apart from possibly some command line parsing and other administrational tasks like organising with input and output files etc.
1 Of course it's possible to have a shell code library that you can also execute. See e.g. Differentiating between running and being sourced in a bash shell script?
The issue that I have with that is that it's not elegant (personal opinion). Other variations are found in this StackOverflow answer which relies on detecting the kind of shell being used and doing things differently for each.
The issue that I have with a library-as-script (apart from relying on somewhat messy code to detect how it's being used) is that it becomes a strange hybrid thing that provides two totally separate functionalities depending on how you call it. It defines functions that another script may pick on choose from when sourced, but it behaves like a command when used as a command. It would be awkward to write the manual for it (what manual section should it be categorised under?)...
I'd rather (and this is still my personal opinion) separate out the library bits into a pure shell library file and source that from whatever user-callable scripts that needs to use it. This would follow the same design that you would also find in shared libraries vs. executable binaries.
