So I have been wondering just what might be going on that some commands work as a normal user while others only work as root and still others only work as a certain type of root. Also, I might add that any time we provide a command to someone else that requires you to be root, we need to indicate the kind of root command, because there is a difference. (The issue of needing to be root has to do with system wide modifications and the need for tight security, a subject that is outside the scope of this message today.)
For instance look at the terminal command:
fdisk -l Absolute path to 'fdisk' is '/sbin/fdisk', so running it may require superuser privileges (eg. root).
Open a terminal session and type this command and you are told of its location and that you might need to be root to get it to run. Humm, OK then how about this:
sudo fdisk -l root's password: sudo: fdisk: command not found
Still not working. So what do you think our unknowing users are thinking? What about this command:
su Password: fdisk -l
And Bam! I get my disk listing just as I was requesting. Humm, why does su work and sudo does not? Perhaps it has something to do with your path. So, I did a test using echo $PATH as a normal user and as different kinds of root and here is what I found:
Using echo $PATH With or Without using sudo (echo $PATH<enter> or sudo echo $PATH<enter>) 01) /usr/lib64/mpi/gcc/openmpi/bin 02) /home/james/bin 03) /usr/local/bin 04) /usr/bin 05) /bin 06) /usr/bin/X11 07) /usr/X11R6/bin 08) /usr/games 09) /opt/kde3/bin 10) /usr/lib64/jvm/jre/bin 11) /usr/sbin 12) /usr/sbin su (su<enter> and echo $PATH<enter>) 01) /usr/lib64/mpi/gcc/openmpi/bin 02) /home/james/bin 03) /usr/local/bin 04) /usr/bin 05) /sbin 06) /bin 07) /usr/bin/X11 08) /usr/X11R6/bin 09) /usr/games 10) /opt/kde3/bin 11) /usr/lib64/jvm/jre/bin 12) /usr/sbin 13) /usr/sbin 14) /usr/sbin su - (su -<enter> and echo $PATH<enter>) 01) /usr/lib64/mpi/gcc/openmpi/bin 02) /sbin 03) /usr/sbin 04) /usr/local/sbin 05) /root/bin 06) /usr/local/bin 07) /usr/bin:/bin 08) /usr/bin/X11 09) /usr/X11R6/bin 10) /usr/games 11) /opt/kde3/bin 12) /usr/lib64/jvm/jre/bin 13) /usr/sbin su - root (su - root<enter> and echo $PATH<enter>) 01) /usr/lib64/mpi/gcc/openmpi/bin 02) /sbin 03) /usr/sbin 04) /usr/local/sbin 05) /root/bin 06) /usr/local/bin 07) /usr/bin 08) /bin 09) /usr/bin/X11 10) /usr/X11R6/bin 11) /usr/games 12) /opt/kde3/bin 13) /usr/lib64/jvm/jre/bin 14) /usr/sbin
So in our very first attempt to run the fdisk command, we were told the program was located in the folder /sbin/fdisk. So the only way this command worked is when we used the su command which placed the /sbin folder in our path. Now, knowing the path, we could have run the program using sudo in this way:
sudo /sbin/fdisk -l
This time, using the sudo command, the fdisk -l command works just fine. For a few other things about the path command. You can add to your path command for a single terminal session by using the following command:
Close the terminal session and it is gone however. What about making it there all of the time, but for your personnel sessions only. Edit the following file, if you use KDE:
kdesu kwrite ~/.profile
And add your new path command there. So, have you learned anything about using the path command? Have I missed something you need to add (which is very likely)? Have I got anything wrong (then correct me)?
If you post a command that needs root permissions, make sure your fellow users know how to make the command work as it takes only a little more effort to show this.
Please, I welcome all comments and all points of view. Lets make this a good thread to read for everyone. Remember you can’t learn if you don’t try and you don’t fail, so that you can see the error of your ways and make the required corrections. Its the only way to learn.
I fail all of the time, even as we speak. lol!