creation of Unix Environment Variables

[BruceD Lindberg]

This is really a Unix OS question but the topic is used by all the Progress Application startup scripts. We have a script that does nothing but create Unix global environment variables, like PROPATH etc. The script is run from other scripts and is prefaced with a period and space; like ". /env.sh". My question is why does the period have to be there. If the script is run from the unix prompt, like "# env.sh", the global variables do not take. Why does the script have to be prefaced with the period for global environment variables to be remembered.

 

[ron]

Unix shells and sub-shells

Hello, Bruce.

The regular behaviour of Unix is that when it executes any script, a new process is spawned. That means (normally!) that the process that commands the execution of the script is temporarily suspended -- and the script then executes in a separate OS process environment. If the script in the new environment causes variables to have values set then those values will only survive for as long as that environment survives. As soon as the spawned process terminates and control resumes in the "calling" script, all values belonging to the terminating process are lost. The "calling" script then wakes-up and resumes "as if nothing had happened".

The dot (by itself) at the start of a Unix command is an instruction to the shell to execute the command within the current process environment. Thus, if the command is a script that sets/alters the values of variables then they are set/altered within the current environment -- which is probably what you want to happen.

I hope that all makes sense!

Regards,
Ron.

 

[BruceD Lindberg]

yes but

Then what does the "export VARIABLE" do? I see lines like
# PROPATH=/rd/src; export PROPATH

if this is executed in the calling scripts environment then why is there a need to export it? Does that change it from a temporary environ memory variable to a remembered one? But why export when the current environment can see it anyways?

 

[ron]

... but ... export does have a purpose!

If a script exports a variable then all sub-shells spawned can access the variable.

If you don't export then the variable's value is only available specifically in the current shell.

To illustrate, take the two scripts, t1 and t2:

# cat t1
#!/usr/bin/ksh
AAA=t1
echo $AAA
./t2
echo $AAA


# cat t2
#!/usr/bin/ksh
echo $AAA
AAA=t2
echo $AAA

If you execute t1 you will see this:

# ./t1
t1
<-- NB
t2
t1

If you change each assignment of variable AAA so that it exports, then you will see this:

# ./t1
t1
t1 <-- NB
t2
t1

So, exporting the value in t1 made the value available to t2.

Note that ksh only provides a "call by value" of exported values to the sub-shell. Values exported in a sub-shell (like t2) would be available to any sub-shells that may subsequently be spawned -- but the values can not be taken back to the higher-level shell (as a "call by name" facility would provide). That's why (in all cases), when we finally return to t1, the value in the variable is always "t1".

Regards,
Ron.