"sudo" Functionality

[Omar Ghalib]

When calling a script to be executed as the owner of the script using sudo, .cshrc found under the users home page is not sourced when setting the first line to be #!/bin/csh. The current workaround is to explicitly source .cshrc in the calling script.

Are we missing some sort of sudo setting or is the user account is not setup correctly?

[Tomek Gryszkiewicz]

try sudo su - user -c command
This will read the users probile

-Tomek

[Patrick Wallek]

Setting the shell in the first line of a script does not cause any behavior other than causing the script to run via that particular shell.

The best practice is to explicitly set whatever environment variable you need within a script.

If you ever want to run this script via cron or at then sourcing a .cshrc or .profile will not necessarily work either since the script is not being run from a terminal. If you do source a .cshrc then it is likely you'd get the infamous "stty: not a typewriter" message since it is assuming that by default anything sourcing the .cshrc or .profile is at a terminal.

[Omar Ghalib]

I do see what you are getting at. There are two servers though, a production one and a development one. Our UNIX outsource partner, may they profit for ever, can not put their hands on the issue as the setup on the development server is working just fine. When we moved into production the START and STOP daemon scripts stopped working in production.

The issue is we have an Oracle repository owned by owner_oracle and an application tier running on UNIX owned by owner_app. We have an automated script that stop the app tier before the database is shutdown and starts it after the database opens.

So the question is why is it working in development while in production its not.

Through testing and trial and error I have developed a work-around that currently works from a terminal but not have tested it yet from cron. The workaround is to directly source .cshrc from the calling scripts.