-
Notifications
You must be signed in to change notification settings - Fork 0
/
DesignNotes
34 lines (28 loc) · 1.91 KB
/
DesignNotes
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
Design Notes for Voyage Linux Scripts
Our overall aim is to provide a "modular" system, with different scripts
providing different functions. However, there is a problem on the method
of communication between scripts. Passing parameters is not a problem,
since the calling routine can provide as many paramaters as are required
for communication. Returning results, however, is not so straightforward.
Basically, any "standalone" script can only return a (numeric) "exit code",
which is an integer value. It cannot provide multiple items of information,
e.g. it cannot return a pointer to a structure, etc.
At first glance, it might appear that "environment variables" could provide
the answer. However, when script 'A' calls (executes) script 'B', all of
the environment variables from 'A' which have been exported can be used
within 'B'. The reverse, however, is not true. If 'B' makes a change to
an environment variable, that change is lost when 'B' exits, and the value
of any environment variable which was changed by 'B' is restored to the
initial value from 'A'.
There are two solutions to this communications problem (that I'm aware of):
first, instead of having 'B' in the above example execute as a completely
separate script, it could be made into a function which is then "source'd" by
A. This works because a function can modify any variables (which have not
beed declared as 'local'). Second, instead of using environment variables,
one can use specified files which are accessed and modified by the different
scripts. This also works, but is not a very nice/clean solution - one
problem is the "protection" of the file used for communications - for example,
what happens when more than one user on the system executes the scripts?
I haven't completely decided on the "best" solution, but I'm heavily leaning
toward having primarily a single "main" script, with all the others being
functions sourced from within the main.