Re: trap cmd ERR (in a function) behavior not consistent

[Carsten P. Gehrke]

At 14:28 13-11-03, Chet Ramey wrote:
> > Machine Type: i686-pc-linux-gnu
> >
> > Bash Version: 2.05b
> > Patch Level: 0
> > Release Status: release
> >
> > Description:
> >       Using trap cmd ERR in a function leads to unexpected results,
> > depending on the cmd and how the function is invoked.  For example, a
> > simple echo command in the trap appears to work as expected when the
> > function is invoked as a simple command (e.g.  on a line by itself),
> > but the trap is ignored when the function is invoked as the condition
> > of an if clause.  To illustrate, consider a function sub1 which
> > contains the statement
>
> There are two issues here:
>
> First, the problem of the trap being effectively ignored when you put a
> `return' in the trap command in sub1.  This is a bug -- the shell doesn't
> clean up after itself well enough when a `return' is executed while the
> shell is executing the trap command.  This has been fixed for the next
> version.
>
> Second, the ERR trap is executed under exactly the same conditions as
> when the shell would exit if `set -e' were enabled.  Those are listed in
> the man page.  Being part of a command executed as the test in an `if'
> statement is one of the conditions under which the shell will not exit.
> The full list is in the man page.
>
> Chet
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ( ``Discere est Dolere'' -- chet )
>                                                 Live...Laugh...Love
> Chet Ramey, ITS, CWRU    chet@po.cwru.edu    http://tiswww.tis.cwru.edu/~chet/

Ah, then I misunderstood the documentation.  I thought that the trap within 
the subroutine would have a different scope than the one in the main 
program.  My interpretation was (given the code below) that the trap in 
sub1 had a different scope than the one in the main program; i.e. the main 
trap is not triggered when sub1 fails, but the sub1 trap does trigger when 
the shell executes command_that_fails.

#!/bin/bash

sub1 ()
{
  trap "return 1" ERR           # sub1 trap

  command_that_succeeds
  command_that_fails

  trap - ERR
  return 0
}

trap "exit 1" ERR               # main trap

if sub1;  then
  echo "all is well"
else
  echo "something is wrong"
fi
exit 0


I guess I got confused by the behavior of my first program:

#!/bin/bash

sub1 ()
{
  trap "echo 'sub1: *** error trapped ***'" ERR

  ./this_fails

  trap - ERR
  return 0
}


echo "Running ${0##*/}..."
echo

trap "echo 'main: *** error trapped ***'" ERR

./this_fails
echo "main: this_fails returned exit status $?"
echo
sub1
echo "main: sub1 returned exit status $?"
echo
./this_fails
echo "main: this_fails returned exit status $?"
echo
exit 0



Running traptest5...

./this_fails will return: FAILURE
main: *** error trapped ***
main: this_fails returned exit status 1

./this_fails will return: FAILURE
sub1: *** error trapped ***
main: sub1 returned exit status 0

./this_fails will return: FAILURE
main: *** error trapped ***
main: this_fails returned exit status 1


Since the trap - ERR at the end of sub1 seemed to restore the scope of the 
main trap, I thought that would also apply to the triggering.

Thank you,
Carsten

P.S.  You mentioned a next version, would that be bash-2.05c?  Is there a 
patch available for 2.05b?  I had checked on the server, but none of the 
patches there seemed to address the "return" problem.


--
========================================================================
                            Carsten P. Gehrke
                     mailto:Carsten@RollingHorse.com
========================================================================