Menu
▾
▴
#529 su -c doesn't work on MacOSX 10.5
closed-fixed
5
2009-08-24
2009-08-07
No
With clisp-2.47 and clisp-2.48 (probably also with older releases), configure fails to install on MacOSX (and probably other BSD systems) when root is needed:
Test passed.
su: illegal option -- c
usage: su [-] [-flm] [login [args]]
Modifying configure tail to something like the following should work better:
if test -n "$do_install"; then
dosu=0
# check whether the destination is writable
if touch ${prefix}/abazonk 2>/dev/null ; then
rm -f ${prefix}/abazonk
if touch ${exec_prefix}/abazonk 2>/dev/null ; then
rm -f ${prefix}/abazonk
else
dosu=1
fi
else
dosu=1
fi
my_su(){
if [ $dosu -eq 0 ] ; then
"$@"
else
case "$(uname)" in
Darwin) su root -c "$@" ;;
*) su -c "$@" root ;;
esac
fi
}
cd "$ABS_DIRNAME"
my_su make install
fi
your version also uses "-c".
Notice the syntax of su on Darwin. Anything following the login name is passed to the shell. The words -c make install given to su on Darwin will be passed to bash, which will thus execute bash -c make install
However, this is still wrong, since this gives only make to -c, and install is used to fill argv by bash.
We could group in a single word the arguments to my_su:
my_su "make install"
(for a generic function we would have to quote-shell-argument the words in my_su to be able to concatenate them in a single string to give with -c).
I think "su root -c foo" would work on other platforms too.
At least su root -c "make install" works both on Darwin and Linux.
(su is not a POSIX standard command, so we can only pray for some commonality here).
'root' does not need to exist or have a password. On the MacOS X 10.5 box I have access to, no one has the password of user "root". Only the user "admin" has a password and administrative privileges.
'sudo' can also not necessarily be used, because it fails for users outside the "wheel" group.
Also, some users might not want that scripts ask for administrative privileges without explaining for what tasks they need them.
In summary, I would move all code that requires administrative privileges to a separate script, and tell the user to execute that script, in a way appropriate to his environment.
yeah, sounds like the best solution is to remove the "install" command altogether.
I can hardly imagine an admin who would do that (Pascal, how did you stumble upon this?)
objections?
I agree that that detail of the installation phase is better left up to the user.
The original configure script entered the su case on my MacOSX just because the prefix directory didn't exist yet. (Without the call to su in configure, I would have used sudo to create the directory and change ownership, and I would have installed it under my user login).
I removed --install altogether; this closes the issue
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).