.profile loses variables set in script evoked from profile

[Bart Touber]

One of our .profiles (copy of a root profile) seems to lose all variables set (exported) in a script run from within this profile. The script is being called right at the back of the profile, and the only workaround we could find was invoking a new shell at the end of the script: /usr/bin/ksh. In the mean time, all aliases seem not to work, whereever they are (in profile or script). What is going on?

Here's the .profile:

# @(#)B.11.11_LR

# Default (example of) super-user's .profile file


# Do not put "." in PATH; it is a potential security breach.
# Do not put "/usr/local/bin" in PATH; it is a potential security breach.
# Example assumes /home/root exists.
set +u

PATH=/usr/sbin:$PATH:/sbin:/home/root

# Be sure that VUE does not invoke tty commands

if [ ! "$VUE" ]; then

# Set up the terminal:
if [ "$TERM" = "" ]
then
eval ` tset -s -Q -m ':?hp' `
else
eval ` tset -s -Q `
fi
stty erase "^H" kill "^U" intr "^C" eof "^D"
stty hupcl ixon ixoff
tabs
TERM=vt220
echo
echo "Value of TERM has been set to \"$TERM\". "
export TERM

EDITOR=vi
export EDITOR
set -o vi

fi # if !VUE


# Set up shell environment:

set - u # error if undefined variable.
trap "echo 'logout root'" 0 # what to do on exit.
umask 022 # set umask u=rwx,g=rx,o=rx

# Set up shell variables:
trap "echo 'logout root'" 0 # what to do on exit.
umask 022 # set umask u=rwx,g=rx,o=rx

# Set up shell variables:

MAIL=/var/mail/root
# don't export, so only login shell checks.
HISTFILE=${HOME}/.sh_history
PS1="$(hostname):\$PWD\#"
export HISTFILE PS1

echo "WARNING: YOU ARE {USER} SUPERUSER !!\n"

export ORACLE_HOME=/appl/oracle/product/9.2

PATH=$ORACLE_HOME/bin:$PATH:.
export PATH

alias -x pas='cd /appl/psoft/; ll'
export pas

/appl/psoft/psconfig.sh

[Pete Randall]

Bart,

I assume that /appl/psoft/psconfig.sh is the script that's setting the variables that are being lost. Given that, the problem would be that, as written, it's spawning a separate shell and the variables are getting set there rather than in this shell. Put a "dot space" in front of it: . /appl/psoft/psconfig.sh


Pete

[Bill Hassell]

Any script that is simply run is always run in a subshell or child process. When the process finishes, all changes in the subshell are lost. To get changes to 'stick' in the current shell, you must 'source' the script (or .profile) and this is accomplished using the shortest command in the shell, namely ".". Also called the dot command, what it does it to ask the current shell to read and interpret each command without using a subshell. This will work for you:

. /somedir/.profile

That first . must be all by itself. Sourcing also works inside a script and used fairly commonly in /etc/profile to set a common set of values:

. /etc/set_oracle_values

[Bart Touber]

Hi Pete

thx for your reply.
We've tried that, but then we get

${HOME:-.}/.profile[63]: IS_PS_PLT: parameter not set

at login.

This IS_PS_PLT is the first variable being called the script /appl/psoft/psconfig.sh, so it doesn't seem to read any of the script's variables in that case.

[Bart Touber]

Indeed, on another machine we use a profile (not a root copy) that invokes the script like this:

. /appl/psoft/psconfig.sh

and that works. But in this profile it doesn't, unless we add /usr/bin/ksh to the script.

And does anybody know why the alias doesn't work?

[Bill Hassell]

I would start by tracing the scripts. Put set -x at the beginning of each script and also inside any functions. Because there are scripts calling scripts, it will be hard to troubleshoot here in the forums. It is not clear at all what you mean by "adding /usr/bin/ksh" to the script. Are you talking about #!/usr/bin/ksh which should be at the begining of every script no matter what?

[Sanjay_6]

Hi,

In the profile that you posted, i do not see the variable IS_PS_PLT defined and exported.

If you don't define and export the variable in .profile, you need to do so in the second script that you are calling from within the .profile

You need to export all variables for the child shells to use that variable.

Hope this helps.

Regds

[Tony Contratto]

Hi Bart,

At about the middle of your profile it runs "set -u". That will cause any reference to an undefined variable to error with the "parameter not set" message you are getting.

You either need to define the variables before they are referenced or remove the "set -u". Defining the variables may be the best bet since the "set -u" behavior can save you a lot of headaches caused by typos in your scripts.

--
Tony

[Bart Touber]

Hi,


I'm afraid all variables are defined and exported in the script /appl/psoft/psconfig.sh before they are referenced anywhere.
Our profile executes the script /appl/psoft/psconfig.sh, with /usr/bin/ksh at the end to invoke a new shell. Without that, the first shell cannot find the variables.
Script /appl/psoft/psconfig.sh is ootb Peoplesoft and does not contain #!/usr/bin/ksh at the beginning.

[Tony Contratto · Accepted solution]

Bart,

Looking at the psconfig.sh file on a PeopleSoft installation here, the IS_PS_PLT variable is referenced in an if statement right at the beginning of the script. That if statement is used to determine if the script should continue (IS_PS_PLT is not set to "Y") or if it has already been sourced (IS_PS_PLT is set to "Y"). If it makes it passed that, then IS_PS_PLT is defined and exported. Is yours the same?

If you run psconfig.sh using:

/usr/bin/ksh -u /appl/psoft/psconfig.sh

you should see the same error you are seeing from your profile (since your profile does a "set -u" prior to sourcing psconfig.sh).

--
Tony

[Bart Touber]

Thanks Tony,

Indeed, the script starts with
if [ "$IS_PS_PLT" = "Y" ]
I just assumed that if this Y is not there, it would just continue with the "else", but it obviously didn't. I exported the variable (and $SHLIB_PATH) in the profile, and it works.
Thanks all for your replies!

Bart

[Bart Touber]

BYE