Problem: su - <username> -c "script" not working and getting -c option not
recognized error.
Thanks to everyone for the quick and very large response. I have pasted
below a representative sample of the replies received with the most common
reply being that it works fine on their system.
In my case I was using the command in a script which was calling it via an
"at" command and I should have added that information to the initial
request. One of the replies suggested that the -c option was meant for cron
and that caused me to look at the "at" environment. I think that was the
problem because by calling it directly instead of via "at" it now works and
the -c option error is not displayed. Still have not succeeded in getting
it to work via "at" but have other fish to fry.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>.
you need a different format of the 'su' command between v4 and v5 ... this
is what I use:
# test for OS version number
ver=`uname -a | awk ' { print $3 } ' | cut -d'.' -f1`
if [ "${ver}" = "V5" ]
then
V5=" -c "
else
V5=""
fi
su dbadmin ${V5} "/usr/bin/rsh $HOST $COMMAND"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
there is indeed no man page in 4.0d, but in my 4.0d system (on a 4100, too,
with Patch Kit 4) the following command works without problems:
su - steffi -c do_something
where do_something is a script lying in my home directory.
Attention: the first "-" has two blanks around it, the "-c" is written - as
usually - without a blank between.
And voila: the man page from 3.2g
su(1) su(1)
NAME
su - Substitutes user ID temporarily
SYNOPSIS
su [-f] | [-c command] | [-] [user]
FLAGS
-c command
Executes the specified command in the user's shell.
-f Prevents the user's shell initialization file from being executed
by
passing the -f option to the user's shell, thus making su start up
fas-
ter.
- Simulates a full login by executing the commands in either
the .cshrc
and .login files for csh or the .profile file for sh and ksh and
by
setting the current working directory to the user's home directory.
>>>>>>>>>>>>>>>>>>>>>>
I tried several variations on my system (4.0D with patch kit 7 installed)
and su - username -c script worked on all except one. That was when the
script did not have execute permission. Are you sure the execute bits are
set? Does the script have a "#!/path/to/interpreter" comment at the top?
BTW, to answer one question, su passes the -c to the shell invoked by the
su - username
>>>>>>>>>>>>>>>>>>>>>>>>
The -c option does work on v4.0d.
In my KSH script that starts and stop my Oracle Apps and DBMS I'm using the
command :
/usr/bin/su - ${DBUSER} -c "ORACLE_SID=$lSID ; export ORACLE_SID ; svrmgrl"
>>$LOGFILE 2>&1
With the env variables assigned appropriately it works flawlessly.
The script may be the name of a script to execute or any other valid command
line. Keep in mind that the environment that the script will execute under
is that of the user that you are su'ing to, so that user's path, etc. must
be set correctly.
>>>>>>>>>>>>>>
Have you tried sudo? It allows a system administrator to give some users the
right to run some commands as root or as another user. I believe it allow
root to run commands as another user, also. Look at the sudo web page at:
http://www.courtesan.com/sudo/
>>>>>>>>>>>>>>>>>>>.
I suggest the su - <username> -c "script" syntax is meant for crontab; ie.
such that cron runs the script instead of a user doing it interactively.
>>>>>>>>>>>>>>>>>>
Try using rsh instead.
# rsh <node> -l <user> <command>
You will need a ".rhosts" file on the remote node though. More information
from "man rsh". Hope this helps.
>>>>>>>>>>>>>>>>>>>>
Jackie R. Miller
Director, Information Systems
Whitworth College
509 777-4486
Received on Fri Feb 23 2001 - 23:22:45 NZDT