'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