From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2970 invoked from network); 1 Feb 2000 18:42:33 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 1 Feb 2000 18:42:33 -0000 Received: (qmail 26983 invoked by alias); 1 Feb 2000 18:42:27 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9512 Received: (qmail 26975 invoked from network); 1 Feb 2000 18:42:27 -0000 To: zsh-workers@sunsite.auc.dk Subject: Re: Problems with trap handling? In-reply-to: "Sven Wischnowsky"'s message of "Mon, 31 Jan 2000 13:07:45 +0100." <200001311207.NAA01858@beta.informatik.hu-berlin.de> Date: Tue, 01 Feb 2000 18:45:18 +0000 From: Peter Stephenson Message-Id: Sven Wischnowsky wrote: > Bart Schaefer wrote: > > function tst() { > > trap return INT > > read -q xx'?Type ^C here: ' > > echo You should not see this. > > } > > > > Execute in 3.1.6-dev-16 and type ^C. Note that you don't leave the "read" > > prompt. Type any plain character; now "read" returns, and the function > > aborts as if interrupted. > > In this incanartion read ends up in read1char() which explicitly does > *not* stop if the read returns with errno==EINTR. So I guess someone > had a reason for doing this way. > > We could either test retflag/breaks/contflag there or give it a flag > that says to stop in case of EINTR and which would be set by bin_read > (via getquery()). I think the answer is it should be testing more flags at this point: whatever's making the function return (i.e. retflag) should make the read return, too. It's certainly correct that EINTR shouldn't make it return --- the problem was that the query aborted if, say, a background job exited, and as far as I can see the same issue applies to any call to read1char(). It's quite possible the same issue comes up at umpteen other places in the code, alas. -- Peter Stephenson