David S. Miller writes the following:
>
>The path to the perl binary is wrong on the first line
>of your hello.pl script.
Obvious, wasn't it? You could also guess that the first line of the hello.pl
script is #!/usr/bin/perl^M and have a pretty good chance of being right.
But why should people like the original poster have to suffer with vague
(some might even say incorrect) error messages like that? The kernel does a
lousy job of reporting errors, because there aren't enough errno values to go
around. If an exec returns ENOENT, what didn't exist? The filename that was
passed in? Sometimes... other times it means the script interpreter didn't
exist, other times it means the ELF interpreter ld-linux.so.* didn't exist.
The kernel chooses to throw such details away and return a generic errno
value, and the user must investigate each of the possible errors that can be
represented by that errno, to figure out which error actually occurred.
There are 132 lines in my asm/errno.h. Can anyone seriously believe that 132
(minus #if/#endif and blank lines in that file) error messages are enough to
adequately explain everything that can go wrong in a syscall? Oh yes, and
lots of them are not even used anywhere. EBFONT?
Why not EINTERPNOENT for execve? And for rename, ESRCNOENT and EDSTNOENT. And
quotactl returning ESRCH will never make sense as long as strerror(ESRCH) is
"No such process". It needs a new errno meaning "No quota entry"
I anticipate this response:
If we add new errnos whenever there's a new error that doesn't fit one of
the existing ones, libc will never be able to keep up!
To which I say int sys_strerror(int,char*,size_t). "But what about i18n" you
ask? I'd rather have a correct error message that I don't understand than one
which I understand but is a lie.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jun 26 2000 - 21:00:06 EST