bug-bash
[Top][All Lists]
Advanced

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

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


From: Carsten P. Gehrke
Subject: Re: trap cmd ERR (in a function) behavior not consistent
Date: Thu, 13 Nov 2003 17:39:48 -0800

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    address@hidden    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:address@hidden
========================================================================




reply via email to

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