Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site watmath.UUCP Path: utzoo!watmath!idallen From: idallen@watmath.UUCP Newsgroups: net.unix-wizards,net.unix Subject: Telling shell command errors from command exit statuses. Message-ID: <8483@watmath.UUCP> Date: Mon, 30-Jul-84 17:17:45 EDT Article-I.D.: watmath.8483 Posted: Mon Jul 30 17:17:45 1984 Date-Received: Tue, 31-Jul-84 00:38:27 EDT References: <8389@watmath.UUCP>, <1153@ihuxr.UUCP> Organization: U of Waterloo, Ontario Lines: 42 >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