'exit(1);' considered useless (slight flame)
Jonathan Biggar
jonab at sdcrdcf.UUCP
Fri Feb 10 03:42:24 AEST 1984
In article <957 at cwruecmp.UUCP> decot at cwruecmp.UUCP (Dave Decot) writes:
>Perror() is not good because it discourages specific messages. The shells
>should say:
>
> % file
> file: data; not executable
>or
> file: program not executable by you
>
>instead of
>
> % file
> file: permission denied
>
There are a couple reasons for this behavior:
1) All the shell does is to do an exec(2) (or variant thereof) on
the file. It lets the kernel decide whether the user is allowed
to execute that file. The kernal only returns the error EACCES
which the shell cannot distinguish between the conditions of
having the execute bit turned off on the file or one of the
directories it searched to get to that file. For security
reasons, it is best for the kernel not to give any more explicit
information to the user.
2) In light of the first reason, one may ask why shouldn't the shell
do what checking it is theoretically able to do? It shouldn't
because that would require adding massive amounts of code to the
shell to detect each possible error condition and report them.
Also, the shell may not be able to determine exactly what the
problem is because it does not have the appropriate permissions.
(How is the shell supposed to tell the difference between a program
that a user does not have permission to execute and data that a
user does not have permission to execute?)
More information about the Comp.lang.c
mailing list