A.Sloman@cs.bham.ac.uk wrote:
> How does a bash script test if it is run by superuser?
if [ `whoami` == root ]
then
# your commands here, e.g.,
echo yes
else
# alternative commands, e.g.,
echo no
fi
works on my fedora core 1 linux system. I don't know whether the whoami
command is absolutely universal. Man pages describe it as equivalent to
"id -un", as if that were more basic. You could also test the values of
the $USER or $UID environment variables, but again I don't know whether
there are systems which don't set those variables.
The spaces immediately inside the square brackets following the word
"if" are important.
You (or at least I) get unhelpful error messages without them. To
really do the job right you should probably test for the existence of
the whoami command before trying to use it, and check that $USER and/or
$UID aren't empty if you want to fall back to them.
if [ -n "`which whoami 2>/dev/null`" ]
and
if [ -n "$USER" ]
perform the relevant tests. "-n" returns true if the following string
is non-empty. (If you want to do your test the other way round, "-z"
returns true if the string is empty.)
Stephen Isard
>From jeffb@jtbest.demon.co.uk Thu Jan 27 14:57:37 2005
Path: news.demon.co.uk!mutlu.news.demon.net!peer-uk.news.demon.net!kibo.news.demon.net!demon!news-lond.gip.net!news.gsl.net!gip.net!easynet-quince!easynet.net!feed4.jnfs.ja.net!feed3.jnfs.ja.net!feed2.jnfs.ja.net!jnfs.ja.net!warwick!news-out.ftel.co.uk!bhamcs!news
From: jeffb@jtbest.demon.co.uk
Newsgroups: comp.lang.pop
Subject: Re: New package for V15.6, now with installation script (Correction)
Date: Thu, 27 Jan 2005 14:57:37 +0000 (UTC)
Organization: cs.bham.ac.uk MAIL->NEWS gateway
Lines: 73
Message-ID: <ctavh1$2bgj$1@soapbox.cs.bham.ac.uk>
X-Trace: soapbox.cs.bham.ac.uk 1106837857 77331 147.188.192.10 (27 Jan 2005 14:57:37 GMT)
X-Complaints-To: abuse@cs.bham.ac.uk
X-Relay-Info: Relayed through cs.bham.ac.uk MAIL->NEWS gateway
Originator: exim@emily
Xref: news.demon.co.uk comp.lang.pop:1399
Stephen, Aaron,
In message <200501271345.j0RDjQSP077209@soapbox.cs.bham.ac.uk>, Stephen
Isard <stepheni@cstr.ed.ac.DELETETHISuk> writes
>A.Sloman@cs.bham.ac.uk wrote:
>
>> How does a bash script test if it is run by superuser?
>
>if [ `whoami` == root ]
>then
># your commands here, e.g.,
>echo yes
>else
># alternative commands, e.g.,
>echo no
>fi
>
>works on my fedora core 1 linux system. I don't know whether the whoami
>command is absolutely universal. Man pages describe it as equivalent to
>"id -un", as if that were more basic. You could also test the values of
>the $USER or $UID environment variables, but again I don't know whether
>there are systems which don't set those variables.
>
At the risk of establishing an ancestor egg-sucking curriculum...
It is sometimes helpful to have a configuration section that maps the
underlying commands into a script's internal namespace, thus you would
source a "configure" script to set things like, $whoami, $os, $shell,
$wm, $cpu. The platform-specific configuration is then available to
anything that wanted to use it and can easily be extended to cover more
quirks, as they are uncovered, without revisiting any of the scripts
that use it.
Your specific tests inside client scripts would then remain simple and
the clarity of the logic would not be clouded with lots of
platform-specific whimsy. The buck, for adding mechanisms for platforms
on which you cannot test, can then be passed to those of us foolhardy
enough to wish to play with them, and you can be confident we won't
break your tested primary logic by messing with your scripts.
For the record, Cygwin will return the user name with "whoami", but it
doesn't tell one whether the user has administrative privileges. This
would be a quirk of any non-Unix system with a Unix-like environment,
that might conceivably otherwise run your scripts, but couldn't make
sense of the concept of "root". (This may also be the case with some
true "Unix" systems with additional privilege management layers for
defined levels of security.)
If the reason you are checking for "root" privileges is that you want to
put files in standard locations, then it might just be better to
determine if you have write access to /usr/bin, etc. You could then
merge this with the target selection, so that your installation script
doesn't say "if I'm root, copy to /usr/bin, otherwise, try $home/bin",
instead, it might provide a "PATH" of successively less preferred
locations for $usrbin, and let the "configure" script set the output
variable to the first one with the required access permissions. You then
have the result easily available for any on-the-fly configuration
mechanisms, such as rewriting $popsys/popenv or $popcom/popenv.
You might wish to support an argument to a "configure" script, such that
when set, it removes from the environment any permanent variables it has
had to establish, so that you can clean up after calling any of your
scripts that use it. For shells like BASH, that support a "local"
syntax, this may not be necessary, but for older shells, there may be no
choice.
Regards,
--
Jeff
|