[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 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
========================================================================