X-Spam-Check-By: sourceware.org
Message-ID: <46820824.6000602@linux.vnet.ibm.com>
Date: Tue, 26 Jun 2007 23:48:04 -0700
From: Richard A Nelson <cowboy AT linux DOT vnet DOT ibm DOT com>
User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070622)
MIME-Version: 1.0
To: Eric Blake <ebb9 AT byu DOT net>
CC: cygwin AT cygwin DOT com
Subject: Re: Bash is broken wrt trap :(
References: <4681CDCD DOT 7030709 AT linux DOT vnet DOT ibm DOT com> <4681DFBD DOT 7040906 AT byu DOT net>
In-Reply-To: <4681DFBD.7040906@byu.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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/