creating menu prompts to source different .env files in .profile

[Joe Johnson]

I have a unix user. It will need to source two different .env files to source different variables.

Do you have an example of a .profile that has a section which prompts the user on login as to which file to source?

Environment #1
. /k01/oracle/proddb/8.1.7/PROD.env

Environment #2
. /k02/oracle/prodappl/APPSORA.env

[James R. Ferguson · Accepted solution]

Hi Joe:

Personally, I would not add interactive prompts to a user's $HOME/.profile unless you condition the processing to *skip* the interactive dialog if the environment isn't a terminal-based (interactive) one in the first place!

That is:

if [ -t -eq 0 ]
then
interact_with_terminal
fi

Regards!

...JRF...

[harry d brown jr]

echo "Which envionment?"
echo "1 for PROD"
echo "2 for APPSORA"
read userenv
if [ "$userenv" -eq 1 ]
then
. /k01/oracle/proddb/8.1.7/PROD.env
else
if [ "$userenv" -eq 2 ]
then
. /k02/oracle/prodappl/APPSORA.env
else
echo "stupid user - log them off"
fi
fi


live free or die
harry

[Darrell Allen]

Hi Joe,

Another way:

while true
do
echo "1) PROD"
echo "2) APPSORA"
echo "Enter Choice: \c"
read OPT
#
case "$OPT" in
1) . /k01/oracle/proddb/8.1.7/PROD.env
break;;
2) . /k02/oracle/prodappl/APPSORA.env
break;;
esac
done

I like James' note about interactive sessions.

Darrell

[Rodney Hills]

If the user knows what is to be selected, then the user can supply that as a parameter following their login id. For example-

Login: joeuser env1
Passwd: *******
...

Then in your .profile you can check for variable "env1".

Do a man on "login" to find out more about passing environmental variables at the login prompt.

-- Rod Hills

[Joe Johnson]

forgive my inexperience, but can you explain what James means a little more? We generally login with X term clients using Reflection. We also have a dumb terminal, but rarely use it. Thanks for the solutions...

[harry d brown jr]

Joe,

What JRF means is that other processes might use that profile, and if you don't program (write code in your script) for it, then those processes will likely fail. Those "other" processes are not interactive terminal users, like cron jobs, at jobs, and such...


live free or die
harry

[James R. Ferguson]

Hi (again) Joe:

Yes, Harry understood my point exactly (thanks, Harry). I'd leave the profile configuration as general as possible. The idea of having separate files which a user (or script) sources to obtain additional environmental variables is quite valid. If these additonal files contain *only* variable declarations (and perhaps aliases) then they can be exploited at command-line or in scripts without regard to whether they are interactive or not.

Regards!

...JRF...

[Mark Fenton]

Or (for the interactive session) present the user a menu that would allow selection of the desired environment - this is an approach that was popular with text-based terminal systems (VAX, AS400, etc) and is quite flexible. The user's profile will point to a screen menu that affords selection of application. Choosing option 1, for instance will give the user environment-1 and launch the appropriate application(s).

An example attached.

[Joe Johnson]

thanks guys...

[Joe Johnson]

I ended up using this...

It looks like it works, but wanted to know what you guys thought...do I have one to many fi in there?
-joe

# Set up Oracle Applications environment:

if [ -t -eq 0 ]
then
echo "Which envionment?"
echo "1 for ORA"
echo "2 for APPS"
read userenv
if [ "$userenv" -eq 1 ]
then
. /k01/oracle/proddb/8.1.7/PROD.env
else
if [ "$userenv" -eq 2 ]
then
. /k02/oracle/prodappl/APPSORA.env
else
echo "stupid user - log them off"
fi
fi
fi