Korn Shell Script not returning variables to parent

[Rory C. Lehane]

Hi,

I'm using a Korn shell on Hp-UX B.11.23

My problem is that an interactive variable assignment runs fine e.g.

# ORACLE_SID=Rencs
# export ORACLE_SID
# echo $ORACLE_SID
Rencs

But, I am unsuccessful if I try to ksh this as a .sh file or run a symbolic link to this file.

# cat .test.sh
ORACLE_SID=Rencs
export ORACLE_SID
echo $ORACLE_SID

Now, run this file but set SID to something else first:

# ORACLE_SID=diff
# echo $ORACLE_SID
diff
# ksh .test.sh
Rencs
# echo $ORACLE_SID
diff

It looks like the called process does not pass the variable back to the parent?

[piyush mathiya]

Look men,

You are exporting variable, then also it will effected while the process is running, it gives the same value to all child proccess too. but it will not give the value after termination of the process to parent process.

like ...

#T="Test" Declaring Variable
#export $T Export in outer shell
#echo $T Print variable
Test
#sh Inner Shell
#echo $T Print variable
Test
#T="Test1" Modify Variable
#export $T Export in inner shell
#echo $T Print variable
Test1
#sh Child inner shell
#echo $T Print variable
Test1
#exit Exit from Child inner shell
#echo $T Print variable
Test1
#exit Exit from Inner shell
#echo $T Print variable
Test


Regards,
Piyush Mathiya

[OldSchool]

if you want the variables to be in the environment of the parent process / shell, then you need to "source" the script that sets them. In the ksh, this is sometimes referred to as "dotting in" the script. in your case, at the command line, run it as follows:

. .test.sh
(Thats "dot space dot test.sh"

Note the space between the two dots. You can do the same thing within a script if you need the values set in ".test.sh" to be available to the parent / calling script

[Steven Schweda]

> . .test.sh

It's unusual to name a script (or script
fragment) dot-something, like ".test.sh".
Did you read somewhere about using
". test.sh", and not see the space between
the dot (".") and the script (fragment) name
("test.sh")?

(When people don't check the "Retain
format(spacing)" box in this forum, spaces
often become very hard to see.)

[Rory C. Lehane]

the dot before the filename was to follow the same format as a .profile because this is a script that runs application specific logicals separate but similar to a ".profile".

The problem remains though:
if I "ksh .test.sh" or ". ./.test.sh" interactively, the logical assignment works in that process, but if I call the script from another script - it will not return the logicals to the calling/parent process.

The logic behind this is that I am trying to setup symbolic links so that a user can login and then either type "test" or "live" which will then run the appropriate script to setup logicals (rather than having separate user accounts).

[Dennis Handly · Accepted solution]

>It looks like the called process does not pass the variable back to the parent?

This is correct. As Piyush said, environment variables go from parent to child, not the other way.

To go the other way you need to try one of these kludges:
1) Return a string from your script and eval it.
2) Return a file and source it.
3) Or source that script (OldSchool)

See this thread:
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1077113

>The problem remains though: ... if I call the script from another script - it will not return the logicals to the calling/parent process.

We told you why. You have to implement one of these kludges.

Or invert how your scripts work.

[Steven Schweda]

> the dot before the filename was to follow
> the same format as a .profile because this
> is a script that runs application specific
> logicals separate but similar to a
> ".profile".

Swell. So, you're hiding your script fragment
from a normal "ls" command. Was that your
intention?

> [...] but if I call the script from another
> script [...]

You don't really "call" a script. You can
run a script ("./script"), in its own
process, with its own environment, so it
can't set any of your variables, or you can
include a script fragment (". ./script"), so
that its commands are executed in the
including ("calling"?) script's process, as
if the script fragment were actually in the
including script at that point, so its
variables are your variables.

> [...]then either type "test" or "live"
> which will then run the appropriate script
> to setup logicals [...]

As explained, "run the script" is exactly
what you don't want. What's wrong with
something like this:

if ; then
. ./test
else
. ./live
fi

... so your main script would be including
the appropriate script fragment?