In oraenv on Steroids Part 1, we demonstrated a way to extract the correct values for $ORACLE_SID and $ORACLE_HOME. Now we need to put it into a script and use it. Let’s just take the commands and put them in a script “oenv” that we will put in our path. We will also add $ORACLE_HOME/bin to our path:
#!/bin/bash export ORACLE_SID=`grep ^$1 /etc/oratab | cut -f1 -d":"` export ORACLE_HOME=`grep ^$1 /etc/oratab | cut -f2 -d":"` export PATH=/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:$HOME/bin:$ORACLE_HOME/bin echo Oracle Sid: $ORACLE_SID echo Oracle Home: $ORACLE_HOME
Running that bad boy:
Sweet! But when we try to use it, it doesn’t seem to work. Even though it seems to be setting up our variables correctly, nothing works. Why?
The reason this doesn’t work is that Unix shell scripts spawn a new shell, and leave the environment unmodified in the shell that started it. In order to include the variables in the current environment, you have to use the source or “.” when invoking the script, i.e:
Works much better now. But remembering to type “source oenv” or “. orenv” is a pain. Why doesn’t work like DOS batch files or SQL*Plus scripts? Actually there is a really good reason? Have you ever had a SQL*Plus script not work because a previous script changed something? Having a environment scope is really nice.
Getting around this annoyance is really easy. All you have to do is add an alias to your .bashrc:
alias oraenv='source oenv'
Logout, and log back in. You can just run “oraenv” from the command prompt and it will work as expected:
That’s it. We now have a script which correctly configures the environment for almost any Oracle installation. In our next hopefully exciting blog, we’ll pimp this scrypt out and add some more.
- Posted in: Tales from the Scrypt