We are researching the possibility of using Oracle 10g Scheduler on Solaris 10 to launch scripts at our site, and the script that I am testing does not get $HOME (and other environment variables) set correctly. Here is the Korn shell script (show_info.ksh):

#!/usr/bin/ksh
id
env | sort

Here is the output from the script when it is executed interactively (I removed the extraneous Oracle variable displays for brevity):

. ./show_info.ksh
+ id
uid=100(oracle) gid=1978(dba)
+ sort
+ env
$
_=/usr/bin/env
DBA_LOGS=/usr/oracle/scripts/logs
EDITOR=vi
HOME=/usr/oracle
LOGINFROM=n.n.n.n
LOGNAME=oracle
PATH=/u01/app/oracle/product/10g/bin:/u01/app/oracle/product/10g/OPatch:/usr/bin:/usr/local/bin:/usr/ccs/bin:/usr/local/sbin:/usr/sbin
PS1=${LOGNAME}-${ORACLE_SID}-${PWD}
PWD=/usr/oracle/jps/oracle_scheduler
SHELL=/bin/ksh
SystemEnvironment=0200P
TERM=dtterm
TZ=US/Eastern
USER=oracle

Here is the output from the script when it is executed by cron—this appears to be running the Bourne shell, despite the Korn bang line, correct?:

+ id
uid=100(oracle) gid=1978(dba)
+ sort
+ env
HOME=/usr/oracle
LOGNAME=oracle
PATH=/usr/bin:
PWD=/usr/oracle
SHELL=/usr/bin/sh
TZ=US/Eastern
_=/usr/bin/env

Here is the output from the script when it is executed by Oracle Scheduler (dbms_scheduler)—this is what I’m trying to “fix:”

uid=100(oracle) gid=1978(dba)
PWD=/
_=/usr/bin/env

Questions:

1. Which shell is running when the script is launched by Oracle Scheduler?
2. How can I get $HOME to be defined correctly?

J

You may need to export all the variables so child processes will see them.

Where does $HOME get set during a process login?

I thought "login" would do it.

The traditional sequence is init -> getty -> login -> shell.

cron is lightweight and doesn't do a full log in, it sort of just impersonates the user.

Can you elaborate a bit--I don't understand what you mean. Can you specifiy the file names that are called during the login process?

Apparently, Oracle Scheduler is even more lightweight. It barely impersonates the user.

I can hardcode some syntax to get around this problem, but we'll need to "rip and replace" a bunch of code if the user changes in the future, or if the disk farm changes, or if whatever else changes.... I'd like to keep the configuration generic and let the system to figure out $HOME at a minimum, and it would be nice if it would populate $SHELL too. From there, I should be able to source whatever other scripts that I need.

Is there a way to figure out which shell is running when $SHELL is not populated?