Re: exec command and error checking

[Jilles Tjoelker <jilles@stack.nl>]

On Tue, Jan 28, 2014 at 02:17:59PM +0100, Guido Berhoerster wrote:
> * Марк Коренберг <socketpair@gmail.com> [2014-01-28 13:16]:
> > $ dpkg -l | fgrep dash
> > ii  dash                                   0.5.7-2ubuntu2
> >                 POSIX-compliant shell

> > $ exec 9<no_such_file && echo TEST
> > dash: 1: cannot open no_such_file: No such file

> > $ exec 9<no_such_file || echo TEST
> > dash: 2: cannot open no_such_file: No such file

> > So, I cannot test this operation without using $?

> No, exec is a special built in and POSIX specifies that
> ...if a redirection error occurs (see Consequences of Shell
> Errors), the shell shall exit with a value in the range 1-125

> dash correctly exits with exit status of 2 as it should. ksh93,
> mksh, and pdksh do the same.

Indeed, this is correct.

You can avoid the exit by prepending 'command':
$ command exec 9<no_such_file || echo TEST
dash: 1: cannot open no_such_file: No such file
TEST

> > in BASH this works as expected (even in sh mode)

> That's either a bug or an intended deviation from the POSIX
> standard, you'll have to ask on the bug-bash list about that.

The inconsistency appears to be in the behaviour on fatal errors in
interactive shells. Strictly speaking, POSIX seems to require that the
shell continue execution with the next command, setting $? to a non-zero
value. Historically, behaviour has instead been to exit with a non-zero
status (if in a subshell) or return to the prompt with $? set to a
non-zero value (if in the top level shell). Dash implements the latter
and I think it is more useful.

Note that the two behaviours are indistinguishable if a single simple
command is entered.

-- 
Jilles Tjoelker