losing $HOME definition

[Michael Langas]

If one looses the $HOME definition, how do you go about recreating it dynamically. I can parse the passwd file myself if I have to, but I have to think there is a system command to take care of it for me.

Thanks again.

[Patrick Wallek]

$HOME should be set to the users home directory by the shell itself when they log in. $HOME is not a variable that is normally defined in /etc/profile or ~/.profile.

Did you move the users home directory while he/she was logged in? If so, can you have them log out and log back in? That should take care of it.

[Sridhar Bhaskarla]

Hi,

Unless the user is modifying the HOME variable inside, it should automatically get assigned. Look at the man page of 'environ' for more information.

The user has to either manually set HOME or logoff|login to get it set (if his/her profiles are not messed up).

-Sri

[Mark Grant]

I don't think I've ever seen anybody lose $HOME.

However, in answer to your sepcific question, no there is no utility to do it (nobody seems to need it) and if you script it, it is one of the rare times that "awk" is simpler than "perl" (Until Merijn proves me wrong, of course)

$HOME=`awk -F: '$1 == "user" { print $6 }' /etc/passwd`

[Michael Langas]

Maybe I didn't state it clearly, but I know it should be dynamic. The problem is that development has gotten in the habit of hardcoding it in .profile because they say it isn't getting created from inside of oracle forms. I don't know enough about oracle to tell them why it isn't getting created.

Inside the form they are using a line like:
HOST(/apps/some_script,NO_SCREEN)

which I've come to understand will execute the script in question. According to them, none of the environment variables are set so they source the .profile in the script which includes the hardcoded $HOME.

Again, I don't know oracle so I can't really even test this.

Assuming the variable isn't set, I want to give them a way to figure it out without hardcoding it. Better still, would be to figure out why it isn't being set.

[Sridhar Bhaskarla]

Hi,

I don't know about oracle forms either. All I know is this from environ man page.

//An array of strings called the environment is made available by
exec(2) when a process begins. By convention, these strings have the
form name=value. The following names are used by various commands
(listed in alphabetical order)://

Having said that, I would suggest them to run

HOST(/usr/bin/env,NO_SCREEN) if possible and see if the output has HOME in it. A child process by default will inherit the environment of the parent process.

I had seen people unknowingly using HOME as their private variables.

-Sri

[A. Clay Stephenson]

This should work and assign HOME to an item within a form:

TOOL_ENV.GETVAR('TERM', :myblock.myitem);

[A. Clay Stephenson]

This should work and assign HOME to an item within a form:

TOOL_ENV.GETVAR('HOME', :myblock.myitem);

[Steven E. Protter]

if [-z "$HOME" ] then
HOME=$PWD
fi

I don't have my reference but that is supposed to be if $HOME is null.

Oracle Forms could care less what the home directory is. I've got a few years running it and I think there is a communications issue here.

Are there forms in users home directories?

SEP

[Bill Hassell]

If $HOME is defined in the user's login (which it will be due to login) then all subprocesses will inherit $HOME. However, if the DBAs are having to source .profile, then there are several serious errors. First, the Oracle process that's having the problem is not part of the user's environment--it has been started with some sort of disconnect mechanism. And second, sourcing .profile is an incomplete and potentially serious security risk. Incomplete because a normal login with a normal shell will source /etc/profile and then .profile, and insecure because .profile is 100% under the control of the user. If the Oracle tool runs this profile on behalf of the oracle user, you are risking a serious compromise of the database by an unhappy hacker.

If the $HOME value is needed, it should be extracted directly from the passwd file using cut as in:

grep ^$USERNAME: /etc/passwd | cut -d: -f

Now the above is a shell command and should replace the use of .profile to set $HOME. The 'loss' of $HOME is not a loss at all, it is the result of some funky or convoluted way of running the process(es). It reminds me a little of the default behavior for xterm, hpterm and dtterm (no profiles are run).

[Michael Langas]

SUMMARY:

Oracle itself doesn't care about $HOME so it doesn't worry about making it avaialable to subprocesses. Our development staff is writting some custom stuff that needs to have $HOME of the user "oracle". Our fix is to make $HOME for the oracle user and $ORACLE_HOME the same place. (it isn't currently) Now they can just set $HOME to $ORACLE_HOME and no more problems.