Re: bash 4, subshells and ERR

[Ian Fitchet]

On May 13, 10:30 am, Stephane CHAZELAS <stephane_chaze...@yahoo.fr>
wrote:
> 2010-05-13, 02:05(-07), Ian Fitchet:
> [...]
>
>
>
> >  ERR is notionally triggered when a simple command fails.  Subshells
> > are both compound commands and do not inherit ERR.  This is what I
> > expect (read: am used to):
>
> > 3.2.0% trap 'echo SIGERR' ERR
> > 3.2.0% ( false; )
> > 3.2.0%
>
> >  However, now I see:
>
> > 4.1.0% trap 'echo SIGERR' ERR
> > 4.1.0% ( false; )
> > SIGERR
> > 4.1.0%
>
> Note that it's the compound command that triggers the "ERR", not
> "false". In zsh, you'd get 2 ERRs, one for "false" and one for
> (false;), both of which exit with a non-zero status.

Hi Stéphane,

 I appreciate that false returning non-zero and the compound command
returning non-zero are separate events.  It used to be the case that
you would have to test $? explicitly after a subshell completed:

 ( false; )
 if [ $? -ne 0 ] ; then
   handle error ...
 fi

 In bash 4.1, the ERR trap now fires when the subshell returns so,
depending on what you do, you may handle the error twice.

 Most compound commands contain lists that are run in the current
shell's context and so any existing ERR trap is triggered in an
intuitive way.  Subshells and (( used to be different and now it looks
like they behave in a more intuitive way -- ie. if a command (simple
or compound) returns a non-zero exit status then trigger the ERR trap,
if any.

 As I say, it's an observation that may catch some people out.

Cheers,

Ian