bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: set -e behaviour. Seems bug. Not the subshell issue!


From: Марк Коренберг
Subject: Re: set -e behaviour. Seems bug. Not the subshell issue!
Date: Tue, 11 Sep 2012 21:24:39 +0600

2012/9/11 Eric Blake <address@hidden>

> On 09/11/2012 05:51 AM, Марк Коренберг wrote:
> > fun()
> > {
> >     echo 'Execute really bad command:'
> >     /bin/false
> >     echo 'should not print this'
> >     return 0
> > }
> >
> > if ! fun; then
> >     echo 'should catch fault here'
>
> Wrong.  '! fun' is executed in a context in which 'set -e' is ignored,
> so ALL commands with 'fun' are executed without error aborts, which mean
> 'should not print this' MUST be printed, and 'should catch fault here'
> must NOT be printed.
>
> This behavior conforms to POSIX.
>
> >
> > Is any way to force "set -e" to work even in such cases?
>
> No, it is already working as specified (just not the way you want).
>
> >
> > If this question asked 1000 times, why not to answer in FAQ (
> > http://tiswww.case.edu/php/chet/bash/FAQ)?
>
>
> http://mywiki.wooledge.org/BashFAQ#BashFAQ.2BAC8-105.Why_doesn.27t_set_-e_.28or_set_-o_errexit.2C_or_trap_ERR.29_do_what_I_expected.3F


Huge thanks for the answer. But faq does not explain this behaviour. So,
questions:
1. Can you give me link (or name of) posix standard where I can read about
this?
2. Is there any workaround (like shopt) that will help for such case? I
have read all shopts, man bash and found nothing.

If it is the POSIX standard, this mean that I can not check return value of
custom function at all, as this implies disabling of "set -e" inside
functions bodies.

>
>
> --
> Eric Blake   address@hidden    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>


-- 
Segmentation fault


reply via email to

[Prev in Thread] Current Thread [Next in Thread]