I'm not sure what best practice is, but the script works fine when running as root. A possible suggestion may be to check whether the current user is root, and if not, throw an error telling the user to run the script as root (eg 'sudo make deb'). I'd say this is probably ideal as it informs the user that root privileges are required to make it work.
if [ $EUID -ne 0 ]; then
echo "Please run this script as root." > /dev/stderr
# etc
fi
If you don't like doing that, perhaps check whether sudo exists (which sudo) before attempting to call it.
Last edit: ZiNgA BuRgA 2014-08-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am OK with modifying the script such that it checks whether the user is root and doesn't use sudo in that case, but any other modification doesn't make sense. When running as non-root, sudo will always be required. Therefore, asking the user to do 'sudo make deb' is just inviting an inevitable bug report when they fail to read the documentation and do 'make deb' instead, resulting in a package whose files have the wrong permissions. Further, 'sudo make deb' is not a good solution, because if the user is building in a directory that root cannot access (which is how I build libjpeg-turbo, actually), then the dpkg command in the script will fail, since it is running as root and trying to output to a non-root directory.
As far as doing 'which sudo', when running as non-root, sudo is required. Therefore, the script is going to fail anyhow if sudo isn't installed. Whether that failure is at 'which sudo' or 'sudo chown blah blah blah' makes no difference. Either way, the user will get the idea very quickly that they need to install sudo if they do 'make deb' and get an error to the effect of 'sudo: command not found'.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You have fair points, although 'sudo make install' seems to be common advice for something similar.
As a user, I'd prefer a script failing to one which elevates its own privileges without my knowledge. I suppose if you've got a special case of root not being able to access the folder, you'll disagree with me there. You may be able to theoretically provide switches to invoke special behaviour, but that probably unnecessarily complicates things.
I'm happy with your suggestion of just not using sudo if user=root. As default Debian installs do not include the sudo utility, I don't consider not having sudo to be a special case, so it would be useful.
Thanks again for your time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Uhhh... yes, because the script uses sudo. If I removed the invocations of sudo, the script would no longer work. What do you suggest I do about this?
Thanks for the fast response :)
I'm not sure what best practice is, but the script works fine when running as root. A possible suggestion may be to check whether the current user is root, and if not, throw an error telling the user to run the script as root (eg 'sudo make deb'). I'd say this is probably ideal as it informs the user that root privileges are required to make it work.
If you don't like doing that, perhaps check whether sudo exists (
which sudo
) before attempting to call it.Last edit: ZiNgA BuRgA 2014-08-02
I am OK with modifying the script such that it checks whether the user is root and doesn't use sudo in that case, but any other modification doesn't make sense. When running as non-root, sudo will always be required. Therefore, asking the user to do 'sudo make deb' is just inviting an inevitable bug report when they fail to read the documentation and do 'make deb' instead, resulting in a package whose files have the wrong permissions. Further, 'sudo make deb' is not a good solution, because if the user is building in a directory that root cannot access (which is how I build libjpeg-turbo, actually), then the dpkg command in the script will fail, since it is running as root and trying to output to a non-root directory.
As far as doing 'which sudo', when running as non-root, sudo is required. Therefore, the script is going to fail anyhow if sudo isn't installed. Whether that failure is at 'which sudo' or 'sudo chown blah blah blah' makes no difference. Either way, the user will get the idea very quickly that they need to install sudo if they do 'make deb' and get an error to the effect of 'sudo: command not found'.
You have fair points, although 'sudo make install' seems to be common advice for something similar.
As a user, I'd prefer a script failing to one which elevates its own privileges without my knowledge. I suppose if you've got a special case of root not being able to access the folder, you'll disagree with me there. You may be able to theoretically provide switches to invoke special behaviour, but that probably unnecessarily complicates things.
I'm happy with your suggestion of just not using sudo if user=root. As default Debian installs do not include the sudo utility, I don't consider not having sudo to be a special case, so it would be useful.
Thanks again for your time.