This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bash is broken wrt trap :(

Hash: SHA1

According to Richard A Nelson on 6/26/2007 8:39 PM:
> Cygwin bash is actually a newer version than Debian/RH ships - but has
> one flaw not shared by the other distributions.

You left out one important fact - exactly which version of bash are you
running on the three machines you tested?

> ERROR="*** ERROR *** ERROR *** ERROR ***";
> trap "echo \"$0:$ERROR\";" ERR;
> if [ -n "$BASH" -a "${OS:0:6}" != 'CYGWIN' ]; then
>         UNWIND="trap 'false' RETURN;return 1";

Traps on ERR and RETURN are not specified by POSIX, so you are already
using non-portable behavior, and are only guaranteed what is documented in
the bash man page.  And you do realize that the release notes for bash 3.2
included this note, in CHANGES:

z.  The inheritence of the DEBUG, RETURN, and ERR traps is now dependent
only on the settings of the `functrace' and `errtrace' shell options,
rather than whether or not the shell is in debugging mode.

So maybe you should investigate all your shell settings, and see what they
are set to in the different environments.  And it very well could be that
upstream changed intentionally between the versions of bash you are
running on the different machines, although the effect you are seeing may
be an unintentional side effect of some other change that was thought to
be harmless.  And maybe the problem isn't in bash, but in your set of
default shell option settings.

At any rate, to my quick glance,

  trap "trap 'false' RETURN; return 1" RETURN

seems reasonable enough.  You are telling the function that on the first
return, it should install a different trap handler on the return, then
return, which triggers the new RETURN trap, which in turn executes false.

On the other hand,

  trap "trap 'false' RETURN; return 1" RETURN
  trap "trap 'false' RETURN; return 1" ERR

seems fishy.  On error, the ERR trap should install a trap handler on
return, then return with a non-zero value - does that count as an error?
And even if the return isn't an error, it then invokes the second RETURN
trap function of false, which IS an error.  So either way, control should
once again invoke the ERR trap, which installs a trap handler on return,
...  Maybe you should also have something in your ERR trap that resets the
ERR trap back to normal, and see if that makes a difference so that the
RETURN trap is not considered as triggering the ERR trap.

You may also want to raise this issue on the bash mailing list, and see if
the upstream maintainer, Chet, has any insight into how he intended for
returns inside of traps to behave.  I'm not quite sure I see any way that
a cygwin-specific patch could be causing this behavior.  But I'll still
try to trace it further, and actually step through bash in a debugger, if
I can find the time.

> ksh93 will propagate the error upwards via the 'return 1' clause.

So it sounds like ksh's interpretation was that return invoked from inside
a trap cannot trigger further traps.  Maybe Chet needs to adopt that rule,

- --
Don't work too hard, make some time for fun as well!

Eric Blake   
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at
Comment: Using GnuPG with Mozilla -


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]