IMPORTANT NOTE: As of Fedora 10, this page will be obsolete. Fedora 10 now puts /sbin, /usr/sbin, and /usr/local/sbin in the normal user's PATH by default.
It is still applicable to CentOS-5.x, which will be supported until early 2017.
Fedora forums will often have a question from a newcomer to the effect that they've used Ubuntu, or that they were following a tutorial and when typing a fairly common command, e.g., ifconfig, they received the error message, "command not found." This has to do with the PATH variable. When you log into a Unix or Unix-like system, you are put in an environment with several things defined. One of these is the environment variable PATH. PATH is where the shell looks to find commands that you type.
To discover your system's PATH environment, you type
echo $PATH |
Putting the $ in front of the variable's name tells the shell, "Give me the current value of the variable." (If you typed echo PATH the shell would merely echo PATH). Fedora and some other systems, especially those that have been around awhile (I believe this is the case with IBM's AIX as well) don't put the /sbin, /usr/sbin and anything else with /sbin in its name in a normal user's PATH. The s in sbin stands for system. Most commands in the sbin directories are system commands. The theory behind this is that commands in these directories can affect the entire system. Therefore, only the root account should have these directories in the account's PATH.
Therefore, commands such as ifconfig, useradd, and many others, which affect the system will be found in places like /usr/sbin or /sbin. If you're not root, these directories aren't in your PATH. That means the shell doesn't look in those directories for the command, and you will get the error message that the command wasn't found.
Newcomers hear about the su command. What they don't realize is that if you type su, although you now have root's privilege, you don't have root's environment. To get root's environment as well, type su - and you will not only have root's privilege's, but also root's environment. (That's su, a space, then a hyphen.)
Otherwise, you will have to type the full PATH to the command, e.g., /sbin/ifconfig or /usr/sbin/useradd.
You can see this for yourself. If you are in your $HOME directory, for example, /home/john and type su, then root's password, you will still be in john's home directory. (You can see this by typing pwd which stands for print working directory.) If you do su - and then type pwd, you'll see that you'll be in root's home directory.
You can always find a command's location, whether you're root or not, by using the whereis command. For example
whereis useradd |
will tell you that it's in /usr/sbin. Doing whereis ifconfig will tell you that it's in /sbin.
Inconvenient as this may be, it can help prevent making mistakes. If you have to type out the full path to a command, it keeps you aware that you are using a command that will affect your system. However, if you do find it too much of a nuisance, it's easily fixed.
My own feeling, especially coming from a BSD background, is that I agree with the statement, "Unix doesn't stop you from doing stupid things because that would also stop you from doing clever things." Therefore, I change my $PATH to include /sbin and /usr/sbin.
Open up your .bash_profile. (That only applies if bash is your default shell. If you used zsh for example, you'd edit your .profile instead.) Add the line
PATH=$PATH:/sbin:/usr/sbin; export PATH |
What you have done is change the value of your PATH variable. Remember, the $ in front of it means the value of the variable. So, you are telling your shell that your PATH variable will be the present value of PATH, plus /sbin and /usr/sbin, the various PATHs separated by colons. Then a semicolon, which is used to separate commands, and the command to export your PATH. If you don't use the export PATH line, then the changed PATH variable might not be available in all programs. Whether one should do this or not is a matter of personal preference. However, sometimes it will save a lot of aggravation. For example, VirtualBox has a script that one uses to create a permanent virtual interface. The script includes some ifconfig commands. If you use it on a RedHat based system, unless you've logged in as root, the script will fail with command not found.
Note that I type, "logged in as root." This is one of those cases where if you log in as regular user, then do an su, you still don't have /sbin in your PATH, so the command will fail.
(You can also run the command source .bash_profile, which should read it.)
The .bashrc file is read with each instance of a shell. For example, if you change your $PATH in .bashrc, then open a new xterm session and type echo $PATH, the new $PATH should be there.
Therefore, although you could put permanent changes to your $PATH in .bashrc, and it will work, it's a bit more efficient to put in in .bash_profile. Then, it only needs to be read once, rather than each time you open a terminal or do anything else in the shell.