[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: set -e behaviour. Seems bug. Not the subshell issue!
From: |
Eric Blake |
Subject: |
Re: set -e behaviour. Seems bug. Not the subshell issue! |
Date: |
Tue, 11 Sep 2012 10:10:40 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 |
On 09/11/2012 09:24 AM, Марк Коренберг wrote:
>> 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).
>>
> 1. Can you give me link (or name of) posix standard where I can read about
> this?
POSIX 2008 Technical Corrigendum 1 is not quite out yet (still in
balloting, but will be finalized later this year), but it will include
this wording:
http://www.austingroupbugs.net/view.php?id=52
> 2. Is there any workaround (like shopt) that will help for such case? I
> have read all shopts, man bash and found nothing.
There's nothing to work around. 'set -e' is behaving as required by
POSIX, which just happens to be a different behavior than what you want.
There is no option in bash to get the behavior you want, unfortunately.
>
> 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.
It doesn't disable 'set -e' inside ALL function bodies, but only inside
function bodies where the function call appears inside a context where
'set -e' is ignored (such as in the condition of 'if'). It's
non-intuitive, and therefore my advice is to never rely on 'set -e'.
--
Eric Blake eblake@redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature