exec command and error checking

exec command and error checking

[Марк Коренберг]

$ 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 $?

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

-- 
Segmentation fault

Re: exec command and error checking

[Guido Berhoerster]

* Марк Коренберг <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.

> 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.
-- 
Guido Berhoerster

Re: exec command and error checking

[Seb]

Le Tue, 28 Jan 2014 18:16:23 +0600
Марк Коренберг a écrit:

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

As previously said, POSIX specifies that the built-in redirection
errors cause the shell to exit. See:

  http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_20
  http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_08_01
  
> $ 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 $?

You can use the file tests:

 if [ -f no_such_file -a -r no_such_file ]; then
   exec 9<no_such_file
 else
   echo TEST
 fi

or a subshell:

 if ( exec 9<no_such_file ) 2>/dev/null; then
   exec 9<no_such_file
 else
   echo TEST
 fi

++
Seb.

Re: exec command and error checking

[Guido Berhoerster]

* Seb <sbb@tuxfamily.org> [2014-01-28 14:41]:
> Le Tue, 28 Jan 2014 18:16:23 +0600
> > So, I cannot test this operation without using $?
> 
> You can use the file tests:
> 
>  if [ -f no_such_file -a -r no_such_file ]; then
>    exec 9<no_such_file
>  else
>    echo TEST
>  fi
> 
> or a subshell:
> 
>  if ( exec 9<no_such_file ) 2>/dev/null; then
>    exec 9<no_such_file
>  else
>    echo TEST
>  fi

That's generally a bad idea since it is racy, if no_such_file is
removeded in between the test and actual exec your script will
still exit. Also, do no use test -a if you care about portability,
it's an XSI extension and marked obsolescent.
-- 
Guido Berhoerster

Re: exec command and error checking

[Seb]

Le Tue, 28 Jan 2014 15:05:23 +0100
Guido Berhoerster a écrit:

> >  [...]
> >  if ( exec 9<no_such_file ) 2>/dev/null; then
> >    exec 9<no_such_file
> >  else
> >    echo TEST
> >  fi
> 
> That's generally a bad idea since it is racy, if no_such_file is
> removeded in between the test and actual exec your script will
> still exit. 

In this case, it will break however, so an half-solution is still
better than no solution at all. Plus you can never be sure a file
will remain available for the life-time of a program, especially in
shell where it must often be accessed by a sequency of different
executables. In this regard, shell progamming is mostly racy, and
the best you can do is to ensure the target exists before dealing
with it, isn't it?

> Also, do no use test -a if you care about portability,
> it's an XSI extension and marked obsolescent.

Indeed. Thanks for pointing this. :)

++
Seb.

Re: exec command and error checking

[Paul Gilmartin]

On 2014-01-28, at 05:16, Марк Коренберг wrote:

> $ 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 $?
> 
> in BASH this works as expected (even in sh mode)
>  
o I believe POSIX (which I haven't read recently)
  allows, but does not require, failure of cd or
  redirection to terminate a noninteractive shell.
  (Were you trying your test interactively or in a
  script?)

o In various shells, I have become accustomed to $? being
  set only by wait() after exec() of a command.

I have become accustomed to dealing with this by coding:
    ( some_command <no_such_file ) && echo TEST
    ( some_command <no_such_file ) || echo TEST

I have never tried to deal with the failure of "exec redirection".

-- gil

Re: exec command and error checking

[Paul Gilmartin]

On 2014-01-28, at 06:17, 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.
>  
My approach, which is often suitable, is such as:

    (   exec 9<some_file || exit $?
            ...
        commands using descriptor 9
            ...
    )

In almost all noninteractive shells I've tried, this
exits with error status either either directly on
failure of the redirection or because of the exit
command.  It's hard, then, to report the error
properly.  Some particularly perverse shells skip the
remainder of the command line upon failure of a prior
command.

-- gil

Re: exec command and error checking

[Jilles Tjoelker]

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

Re: exec command and error checking

[Guido Berhoerster]

* Jilles Tjoelker <jilles@stack.nl> [2014-01-28 23:06]:
> On Tue, Jan 28, 2014 at 02:17:59PM +0100, Guido Berhoerster wrote:
> > 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

bash actually exhibits this behavior as a non-interactive shell
and in POSIX mode as well.
-- 
Guido Berhoerster

Re: exec command and error checking

[Chet Ramey]

On 1/28/14, 4:59 PM, Jilles Tjoelker wrote:

>> 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.

It's a bug in bash.  Bash doesn't exit when the command is on the LHS
of a || or &&.

Chet


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/