Shell error exit question

Leo de Wit leo at philmds.UUCP
Thu Aug 11 06:41:35 AEST 1988


In article <354 at marob.MASA.COM> daveh at marob.UUCP (Dave Hammond) writes:
>Dumb question #4,287 -
>
>How does one get /bin/sh to NOT exit when processing a script which produces
>"not found", or other potentially recoverable errors ?
>
>Yes, I RTFM: according to the manual, "Errors detected by the shell ...
>cause the shell to return a nonzero exit status. If the shell is being used
>noninteractively, execution of the shell file is abandoned."

Maybe you should RTFMMC (... more closely 8-): it says:
Errors detected by the shell; a 'not found' error is not always generated
                ^^^^^^^^^^^^
by the shell (for instance by 'ls' instead); if it IS generated by the shell
I doubt that you can call the error recoverable (for instance a program
to be started by the shell that is not in the PATH). Other types of errors
that are meant here are syntax errors, or failing redirections, or
builtin commands that fail ( for instance: cd). Even a non-interactive
shell does NOT abandon when a succesfully forked process returns a
non-zero exit status, unless you set explicitly the -e flag (by 'set
-e' or invoking the shell with this flag:  sh -e <file>).

I suggest you read the article 'An Introduction to the UNIX Shell' by S.R.
Bourne, notably section 3.5: Error handling; it handles the matter more
clearly than the man pages.

>The reason I suspect there's a work-around is that I've tried the same script
>with Ksh and it merrily continues processing even if "not found" errors occur.

Please be more specific about what the script does.
As for avoiding an exit because a command could not be found, execute it in
a subshell: (command).

>Thanks in advance for any help.

Hope I was of any.

>Dave Hammond                                                /dsix2!daveh
>  UUCP: {uunet | rutgers | spl1 | ...}!{masa.com | hombre}!<
>DOMAIN: dsix2!daveh at masa.com                                \marob!daveh
>----------------------------------------------------------------------------

    Leo.



More information about the Comp.unix.questions mailing list