idallen@watmath.UUCP (07/31/84)
>From: stanwyck@ihuxr.UUCP (Don Stanwyck) > >Obviously the author of the above lines expects the echo to be executed. >If [s]he didn't, [s]he would have used || or && instead of the ;. Are "command not found" and "search pattern not found" the same kind of error? grep bleen file && date nosuchcommand && date cmd >nosuchfile && date cmd nosuchglob* && date In the shells with which I am familiar, only the first exit status is set by the command itself. The Shell fakes the other three exit statuses, because the command (on the left) is never executed. Is it fair to fake an exit status for the user? What business does the Shell have doing that sort of thing? I want to argue that the Shell's job is to correctly start commands and return their error status. If the Shell can't start a command because of a Shell error, it has no business faking a return status and thus pretending it did. This kind of distinction isn't a problem with commands separated by '&&', since you abandon the subsequent command on an error, regardless of what the error is. But you weaken the power of '||' if you lump shell errors in with non-zero return codes from successful programs. grep bleen file || echo "bleen" >>file grez bleen file || echo "bleen" >>file With the weak interpretation of '||', both these lines add "bleen" to "file", because the shell fakes a non-zero return code instead of admitting it couldn't find the command "grez". With a stronger interpretation of '||', you could be assured that "bleen" would be added to "file" *only if a proper call of grep returned non zero*. Of course, if exit statuses had been designed so that there were stanard distinct values for "negative status" and "command didn't get started because of error", then the Shell could fake the latter status, just as any command could return that same status (like GREP returing 2 for an improper invocation). -- -IAN! (Ian! D. Allen) University of Waterloo
ka@hou3c.UUCP (Kenneth Almquist) (08/04/84)
The shell has (presumably) already forked off a child process by the time it discovers that a command does not exist. Therefore, the only way it *can* indicate that the command does not exist is to return a nonzero exit status. Perhaps a special exit status should be reserved for "command does not exist". Kenneth Almquist