invoking a different .profile from command line or script

[Chris Elmore]

This request for assistance is going to sound very simple to someone but I have searched the online man pages, my copy of HP-UX 11i System Administration (by Poniatowski) and the forums for a hint at how to invoke the .profile of another user from the command line or a script while I am logged on as root, so that I can run a SQL script which is dependent on that .profile's enviroment settings. I know it can be done because it says so in the book but the actual command isn't given, I have tried using the exec /path/.profile to no avail. Help please! Thanks in advance to the one who helps me solve this.

[Sean OB_1]

What do you mean when you say to no avail?

It doesn't run? Or the vars aren't set? etc.

[Sean OB_1]

Also, try this:

. /path/to/.profile

[John Poff]

Hi,

You can simply dot in the users profile as root:

. /home/users/somebody/.profile

This will pickup the environment for that user. Probably not the safest and most secure thing to do. You can also use 'su -' to pick up the environment of the user:

su - somebody -c '/usr/bin/dosomething'

JP

[James R. Ferguson]

Hi:

The dot_blank_filename syntax already provided is known as "sourcing" the . To "source" is to read.

Regards!

...JRF...

[Tony Contratto · Accepted solution]

Even though the following will work:
. /path/to/.profile

I would consider this to be a BIG security problem. The user could then edit the .profile and add any shell code they wanted to run as root and the next time you run your script or that cronjob kicks off... you just gave root access to your system by this user.

I would suggest using the "su - somebody -c '/usr/bin/dosomething'" method that John suggested.

-OR-

Create your own file with the environment variables you need setup that you can source when you need it. At least this way only root can edit the file.

[Roger Crettol]

Hello Chris !

This is slightly off-topic, but you may give it some thought.

When working as an administrator, I've become accustomed to grouping common application profiles in an /env/ directory. The specific profiles are owned by root and readable by anyone, and the user profiles then 'source' /env/.oracle or /env/.openview, or whatever.

It makes it easier to migrate - say, part of the userbase to a new oracle release, and there's less of an administration hassle, in the end....

-rg-