When you encounter a problem on a Unix-like system such as Linux, you must read the error message. Unlike messages from other operating systems, Unix errors usually tell you exactly what went wrong.
Most Unix programs generate and report the same basic error messages, but there can be subtle differences between the output of any two programs. Here is an example that you'll certainly encounter in some form or other (the error message is in boldface):
$ ls /dsafsda ls: /dsafsda: No such file or directory
There are three components to this message:
The program name, ls. Some programs omit this identifying information, which can be annoying when you are writing shell scripts, but it's not really a big deal.
The filename, /dsafsda, which is a more specific piece of information. There's some problem with this path.
The specific error, No such file or directory, indicates the problem with the filename.
Putting it all together, you get something like "ls tried to open /dsafsda but couldn't because it does not exist." This may seem kind of obvious, but these messages can get a little confusing when you run a shell script that includes an erroneous command under a different name.
Always address the first error first. For example, some programs report that they can't do something before reporting a host of other problems. For example, let's say you run a fictitious program called scumd, and you see this error message:
scumd: /etc/scumd/config: No such file or directory
Following this is a huge list of other error messages that looks like a complete catastrophe. Don't let those other errors distract you. You probably just need to create /etc/scumd/config.
Do not confuse error messages with warning messages. Warnings often look like errors, except that they contain the word "warning." A warning usually means something is wrong but that the program will try to continue running anyway. To fix a problem noted in a warning message, you may have to hunt down a process and kill it before doing anything else (you'll read about processes in Section 1.16).
Many of the errors that you will encounter in Unix programs result from things that can go wrong with files and processes. Here is the error message hit parade:
This is the number one error. You tried to access a file that does not exist. Because the Unix file I/O system does not discriminate between files and directories, this error message occurs everywhere. You get it when you try to read a file that does not exist, when you try to change to a directory that isn't there, when you try to write to a file in a directory that does not exist, and so on.
In this case, you probably tried to create a file that already exists. This is common when you try to create a directory with the same name as a file.
These messages pop up when you try to use a file as a directory, or a directory as a file. You may have to hunt around a little after you see the error message. Here is an example:
$ touch a $ touch a/b touch: a/b: Not a directory
Notice that the error message only applies to the a part of a/b. When you encounter this problem, you may need to dig around a little to find the particular file that is being treated like a directory.
You're out of disk space. See Section 2.4.7 for information on how to manage this.
You get this error when you attempt to read or write to a file or directory that you're not allowed to (that is, you have insufficient access privileges). This includes the case when you try to execute a file that does not have the execute bit set (even if you can read the file). You will read more about permissions in Section 1.17.
This usually happens when you try to kill a process that you don't own.
A segmentation fault essentially means that the person who wrote the program that you just ran screwed up somewhere. The program tried to access some part of memory that it was not allowed to touch, and the operating system killed it. A bus error is similar, except that it tried to access some memory in a particular way that it shouldn't. When you get one of these errors, you might be giving a program some input that it did not expect.