carydb
asked on
environment variables
I have a script in rc2.d (S80ostore4) this sets some environment variables and then runs the Ostore license manager. On my old system, I can type echo $OS_ROOTDIR and I get /opt/ODI/OS5.0/sunpro.
When I type this on my new system, The $OS_ROOTDIR returns a blank line.
It is the same script in /etc/rc2.d on both machines. What are some reason for the new machine to not keep exported variables???
Can I get some help in making these exported variables maintain their value throughout all the new session.
When I type this on my new system, The $OS_ROOTDIR returns a blank line.
It is the same script in /etc/rc2.d on both machines. What are some reason for the new machine to not keep exported variables???
Can I get some help in making these exported variables maintain their value throughout all the new session.
Start the script with
. ./script
and the environment variables is OK !!!
First point is for environment variables
in your shell.
. ./script
and the environment variables is OK !!!
First point is for environment variables
in your shell.
point, blanc, point,slash,script
ASKER
okay, Here is the script. It is in /etc/rc2.d so it runs automatically when system is booted. After it runs, the $OS_ROOTDIR var is no longer set. Apparently it reamins set only through the execution of the script.
#!/sbin/sh
# Generated automatically by osconfig on Wed Oct 28 12:12:55 EST 1998
# [ ObjectStore Release 5.0 ]
USAGE="Usage: $0 <start | stop>";
if [ $# -ne 1 ]; then
echo $USAGE;
exit 1;
fi
OS_ROOTDIR=/opt/ODI/OS5.0/
export OS_ROOTDIR ;
PATH=/opt/ODI/OS5.0/sunpro
export PATH ;
echo $PATH
LD_LIBRARY_PATH=$OS_ROOTDI
export LD_LIBRARY_PATH ;
SHLIB_PATH=$OS_ROOTDIR/lib
export SHLIB_PATH ;
action=$1;
UNAME=`uname -n`;
case $action in
start_msg)
echo "Starting ObjectStore server"
;;
stop_msg)
echo "Shutting down ObjectStore server"
;;
start)
if [ ! -d /tmp/ostore ] ; then
mkdir /tmp/ostore;
chmod 775 /tmp/ostore;
fi
if [ -f /opt/ODI/OS5.0/sunpro/etc/
if ossvrping ${UNAME} > /dev/null 2>&1 ; then
:
else
/opt/ODI/OS5.0/sunpro/lib/
res=$?;
if [ $res -ne 0 ] ; then
echo ObjectStore server startup failed 1>&2;
exit 1;
fi
fi
fi
;;
stop)
if /opt/ODI/OS5.0/sunpro/bin/
/opt/ODI/OS5.0/sunpro/bin/
fi
/opt/ODI/OS5.0/sunpro/bin/
;;
*)
echo $USAGE;
exit 1;
;;
esac
exit 0;
#!/sbin/sh
# Generated automatically by osconfig on Wed Oct 28 12:12:55 EST 1998
# [ ObjectStore Release 5.0 ]
USAGE="Usage: $0 <start | stop>";
if [ $# -ne 1 ]; then
echo $USAGE;
exit 1;
fi
OS_ROOTDIR=/opt/ODI/OS5.0/
export OS_ROOTDIR ;
PATH=/opt/ODI/OS5.0/sunpro
export PATH ;
echo $PATH
LD_LIBRARY_PATH=$OS_ROOTDI
export LD_LIBRARY_PATH ;
SHLIB_PATH=$OS_ROOTDIR/lib
export SHLIB_PATH ;
action=$1;
UNAME=`uname -n`;
case $action in
start_msg)
echo "Starting ObjectStore server"
;;
stop_msg)
echo "Shutting down ObjectStore server"
;;
start)
if [ ! -d /tmp/ostore ] ; then
mkdir /tmp/ostore;
chmod 775 /tmp/ostore;
fi
if [ -f /opt/ODI/OS5.0/sunpro/etc/
if ossvrping ${UNAME} > /dev/null 2>&1 ; then
:
else
/opt/ODI/OS5.0/sunpro/lib/
res=$?;
if [ $res -ne 0 ] ; then
echo ObjectStore server startup failed 1>&2;
exit 1;
fi
fi
fi
;;
stop)
if /opt/ODI/OS5.0/sunpro/bin/
/opt/ODI/OS5.0/sunpro/bin/
fi
/opt/ODI/OS5.0/sunpro/bin/
;;
*)
echo $USAGE;
exit 1;
;;
esac
exit 0;
Is normal , if a process work
is in your shell.
Example:
This script:
export TEST
echo 'HALLO'
If you start with:
./script
HALLO
end if you make
echo $TEST
is nothing.
If you start with:
. ./script
HALLO
end if you make
echo $TEST
/usr
is in your shell.
Example:
This script:
export TEST
echo 'HALLO'
If you start with:
./script
HALLO
end if you make
echo $TEST
is nothing.
If you start with:
. ./script
HALLO
end if you make
echo $TEST
/usr
ASKER
This script is in the /etc/rc2.d directory and is envoked at system boot up. I do not envoke it on the command line. I don't have the option of envoking it myself. The system runs it at boot up. It works fine on a different machine.
I tried to envoke it as you suggested but the screen disappeared.
I tried to envoke it as you suggested but the screen disappeared.
depending on your shell, you need to write the environment variabl settings in the appropriate rc-files, like:
~/.profile or ~/.cshrc or ~/.login
(don't forget to export)
~/.profile or ~/.cshrc or ~/.login
(don't forget to export)
ASKER
Let me revise the problem. The reason that the variables do not remain set is that for some reason when any script on my system is sourced
. ./scriptname
If there is an exit(0) command in it, It just blows away the window in which the script was attempting to run.
there is something wrong with my system for it to not run scripts that have exit(0) in it.
Is this a known problem in Solaris 8? Any ideas?
. ./scriptname
If there is an exit(0) command in it, It just blows away the window in which the script was attempting to run.
there is something wrong with my system for it to not run scripts that have exit(0) in it.
Is this a known problem in Solaris 8? Any ideas?
no, if you source a script, it runs in the context of the current shell, thus any exit in sourced script is an exit from the current shell. rc scripts are not designed to be sourced, if you need the env vars, put the defs elsewhere and source that.
ASKER
ecw, Ohh! I see. But I do have the rc2.d script that exports env variables just fine for a machine running 2.6
My new machine running 2.8 does not maintain these variables after the rc2.d script (S80ostore4) completes running.
How can this be.
My new machine running 2.8 does not maintain these variables after the rc2.d script (S80ostore4) completes running.
How can this be.
please post results of following:
\uname -a; \echo $SHLVL; \echo $SHELL; \which $SHELL; \which exit
\uname -a; \echo $SHLVL; \echo $SHELL; \which $SHELL; \which exit
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
As ecw posts, probably there is a different settimg of the variable in your previous environment. By the way, in you 2.6 env, what is the login that has the variable set?
ASKER
Sheesh! Just when I thought I had it figured out.....
The /etc/profile was in fact setting the env variables. I was thown off because the rc2.d script to which I referred actually exported those vars. I guess that was to initially run the ostore program and then users had their env set with the /etc/profile.
Live and learn. Thanks.
The /etc/profile was in fact setting the env variables. I was thown off because the rc2.d script to which I referred actually exported those vars. I guess that was to initially run the ostore program and then users had their env set with the /etc/profile.
Live and learn. Thanks.
Cheers - Gavin