Calling a script from another

Hi,

I have 2 scripts, one is the .profile and the other is a SID selector for Oracle Databases.

But when I call one from the other, even though it seems to have worked, it doesn't.

Can anyone help??

******************* .profile**********************

#!/bin/ksh

. /data/u/amin/oracle/oraenv.sh

***************** . oraenv.sh (SID Selector)
#!/bin/ksh

# Environment Variables for Oracle 92

export ORACLE_BASE=/oracle
export ORACLE_HOME=/oracle/92
# PATH=$ORACLE_HOME/bin:$ORACLE_HOME/Apache/Apache/bin:$PATH
export ORACLE_OWNER=oracle
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/usr/openwin/lib:/usr/dt/lib
export PATH=$ORACLE_HOME/bin:$PATH

# Oracle Environment SID Selector

# Script to select From the Multiple SIDs on this machine
echo
echo
echo "The following SIDs reside on this Box"
cat /var/opt/oracle/oratab | awk -F: '{print $1}' | grep -v "#"
ORAENV_ASK=YES
/usr/local/bin/oraenv

Can anyone help??

Ta.

Deln

Could it be that the last line in oraenv.sh

/usr/local/bin/oraenv

should be

. /usr/local/bin/oraenv

?

I found out that as this goes through Exceed, it is waiting for a prompt we can't see, which is why. Apparently, someone tells me this script will never work in Exceed. I am yet to accept that.

It however works from Console or Telnet.

Thanks,

Del.

Why would you call your oraenv shell from within your .profile? Why not let your users simply run the shell? If this is not working through Exceed but it is working through Telnet, are you sure that your .profile is even getting sourced? This is a common problem in our environment when using Exceed.

If you login to Exceed, then manually source your .profile, what happens?

I am by no means a DBA, but what happens when you change this line: ORAENV_ASK=YES to ORAENV_ASK=NO.

I am manually sourcing this and it works. I thought I could do it the other way, but obviously not. Many thanks for your help. Changing ORAENV_ASK=NO will only change the way the SIDs are selected when listed, but the issue is with the line where it calls the executable.

I think I will stick with the manual sourcing. Thanks a lot for all your help.

Delboy.

When logging into the system using Exceed, I dont think your .profile is being sourced.

In your /home directory, look for a hidden file called .dtprofile. In it, make sure that DTSOURCEPROFILE variable is set to TRUE.

We have had similar issues here at work (I use HPUX 11.). See if setting this variable works. (make sure its not commented out if it is already set to true!)

Example.
DTSOURCEPROFILE=true

[URL=http://docs.hp.com/cgi-bin/fsearch/framedisplay?
top=/hpux/onlinedocs/B1171-90162/B1171-
0162_top.html&con=/hpux/onlinedocs/B1171-90162/00/00/20-con.html&toc=/hpux/onlinedocs/B1171-90162/00/00/20-
toc.html&searchterms=dtprofile&queryid=20040902-051212]Quote From This site 

Optionally Sourcing the .profile or .login Script
Xsession is able to source a user's traditional
HomeDirectory/.profile or HomeDirectory/.login scripts. By default
this capability is disabled. To tell Xsession to source the .profile 
or .login script, set DTSOURCEPROFILE to true.

To change DTSOURCEPROFILE for all users, create 
an /etc/dt/config/Xsession.d script that sets the new value. To 
set DTSOURCEPROFILE to true for all users, create an executable 
sh or ksh script, for example
/etc/dt/config/Xsession.d/myvars, and set DTSOURCEPROFILE as
follows:

DTSOURCEPROFILE=true

Users can similarly change DTSOURCEPROFILE for their own 
sessions by setting DTSOURCEPROFILE to true in 
HomeDirectory/.dtprofile.