Mail Archives: cygwin/2007/06/27/02:48:28
Eric Blake wrote:
> You left out one important fact - exactly which version of bash are you
> running on the three machines you tested?
I attached a minimal working script to my most recent reply to this topic
Here's more information on two such systems:
-----------------------------------------------------------------------------
OS=AIX
bash=3.00.16(1)-release
braceexpand on
hashall on
interactive-comments on
>>main
>>do_a
>>do_b
./sample/do_b: *** ERROR *** ERROR *** ERROR ***
<<do_a
./sample/do_a: *** ERROR *** ERROR *** ERROR ***
./sample: *** ERROR *** ERROR *** ERROR ***
OS=AIX
ksh93
trackall on
>>main
>>do_a
>>do_b
./sample/do_b: *** ERROR *** ERROR *** ERROR *** <<
./sample/do_b: *** ERROR *** ERROR *** ERROR *** << Works, looks odd
./sample/do_b: *** ERROR *** ERROR *** ERROR *** <<
-----------------------------------------------------------------------------
OS=Linux << RH EL WS 4 (Nahant)
bash=3.00.15(1)-release
braceexpand on
hashall on
interactive-comments on
posix on
>>main
>>do_a
>>do_b
./sample/do_b: *** ERROR *** ERROR *** ERROR ***
<<do_a
./sample/do_a: *** ERROR *** ERROR *** ERROR ***
./sample: *** ERROR *** ERROR *** ERROR ***
OS=Linux
ksh93
trackall on
viraw on
>>main
>>do_a
>>do_b
./sample/do_b: *** ERROR *** ERROR *** ERROR ***
./sample/do_b: *** ERROR *** ERROR *** ERROR *** << Again, odd but ok
./sample/do_b: *** ERROR *** ERROR *** ERROR ***
-----------------------------------------------------------------------------------
>> 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.
Eep, I was looking about, but missed that factoid :(
> 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.
I'm going through the settings, and found another machine where things don't
work as expectd (Debian ppc, at least w/ppc64 kernel) :(
> At any rate, to my quick glance,
>
> f(){
> 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.
Well, thats not quite what I have, but the overall analysis is close:
trap 'echo "./test/do_a: *** ERROR *** ERROR *** ERROR ***";trap
'\''false'\'' RETURN;return 1' ERR
So, when a command returns non-zero:
* echo "ruh roh"
* set a return trap (executing false)
* return to caller with return code 1
I first thought that just returning with rc=1 would cause the ERR trap in the
parent function to trigger, but no such luck :(
However, the return trap is defined to execute in the context of the caller,
after the called function has completed... and since all it does is execute
'false', it does cause the parents ERR trap to trigger, and things go pretty
smoothly (on some machines).
> 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.
A good idea, I'm collecting more information and looking at your suggestions
since I found another failure case
>> 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,
> too?
Actually, Ksh93 behaviour seems very simple - and matches what I expected:
trap 'echo "./test/do_a: *** ERROR *** ERROR *** ERROR ***";return 1' ERR
* Upon any failing command:
* echo "ruh roh"
* return 1 to the caller
* the caller sees rc=1 and raises ERR
* percolate...
> - --
> Don't work too hard, make some time for fun as well!
Sound advice, right now, however, I'll just settle for sleep :)
Thanks,
--
Rick
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -