How to show that a script should be run as root in Linux

Question

I am writing technical documentation for a smalll project I wrote in college. How do I show that script should be run with root privileges?

My main question is what is the norm of depicting show a scenario? I can of course write that 'run the script with root privileges', but I thought I had ask here.

Should I do :

Run the script with X:

    ./script.py X

PS: Never handled UNIX much before so please don't flame :)

Answer 1

One thing you can do is to show the shell prompt and distinguish it between root and normal user, like

$ ./script
# ./script

Where the $ is the prompt of a normal user and # is the prompt when you are root.

Another option would be to use "sudo".

Answer 2

If your target system supports sudo, you can use the following:

$ sudo ./script.py X

Answer 3

You should both say that the script must be run as root and explain how to do it.

The most common method for executing something as root nowadays is sudo ./script.py X. Your documentation should treat this as the recommended method for most users unless they know better or fail.

Another method is su -c "./script.py X"; this requires nested quoting of X if it contains shell metacharacters. A basically equivalent method is to run just su, then ./script.py X at the root shell prompt.

If you're showing shell prompts, a traditional convention is to use $ or % at the end of the prompt for non-root users, and # for root. However, most unix users today don't know this convention, so if you use it you'll have to explain it.

Answer 4

Do you want the script to fail if it is not being run as root? The os.geteuid() routine can get the effective user id of the user who is running the script, and AFAIK, the euid of root is always 0. You can do the check, printing out an error message if the user is not root.

if os.geteuid() == 0: #or maybe if not os.geteuid()
    print "Running as root!"

else:
    print "Not running as root!"

This way, the code is more self-documenting, so you don't have to rely so much on the README you write.

Answer 5

You could write a short script to call that script (or do it within the original script) where you test if a DISPLAY variable is set and if gksu is available to use gksu or fall back to su otherwise. (You could also test for the KDE equivalent, kdesu, I think.)

gksu has the advantage that it's better integrated with the GUI, which is useful if you expect your users to click on the script (which is good for people who are not familiar with terminals).