From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14766 invoked from network); 7 Feb 2000 12:53:21 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 7 Feb 2000 12:53:21 -0000 Received: (qmail 5911 invoked by alias); 7 Feb 2000 12:53:10 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9599 Received: (qmail 5904 invoked from network); 7 Feb 2000 12:53:10 -0000 Date: Mon, 7 Feb 2000 11:25:02 +0100 (MET) Message-Id: <200002071025.LAA32288@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Fri, 4 Feb 2000 16:31:39 +0000 Subject: Re: Infinite loop (bug in wordcode evaluation?) Bart Schaefer wrote: > On Feb 4, 10:08am, Sven Wischnowsky wrote: > } Subject: Re: Infinite loop (bug in wordcode evaluation?) > } > } Bart Schaefer wrote: > } > } > } The problem is that none of the functions in loop.c check if retflag > } > } is set and hence don't return. > } > > } > I can't find any loop construct in 3.0.7 that produces this behavior, > } > yet 3.0.7 does not have any of those extra retflag tests in loop.c. > } > > } > Does anyone know what else might have changed to cause this problem? > } > } Found it. getkey() in zle_main.c now resets `breaks' to the value it had > } before, so that the new value stored in bin_break() set by the signal > } handler doesn't make it through to the execution code. > } > } Dunno where this comes from, though. > > It came from zsh-workers/7038, something to do with making _read_comp > work correctly. Yep. One could say that that patch explictly implemented the behaviour we now consider buggy. Almost. At least it makes a `break' in a signal handler have no effect if the signal arrives while we are reading with zle (and the handler for SIGINT has an implicit `break', breaking all loops). Hm. If 7038 is still considered to be correct, then my patch is probably the right supplement for it to make `return' in signal handlers work. At least I don't see another way out at the moment. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de