From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-14852-mason-zsh=primenet.com.au@sunsite.dk>
Received: (qmail 8259 invoked from network); 11 Jun 2001 18:36:26 -0000
Received: from sunsite.dk (130.225.51.30)
  by ns1.primenet.com.au with SMTP; 11 Jun 2001 18:36:26 -0000
Received: (qmail 28059 invoked by alias); 11 Jun 2001 18:36:00 -0000
Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm
Precedence: bulk
X-No-Archive: yes
X-Seq: 14852
Received: (qmail 28044 invoked from network); 11 Jun 2001 18:36:00 -0000
X-Envelope-Sender-Is: Andrej.Borsenkow@mow.siemens.ru (at relayer david.siemens.de)
Message-ID: <3B251030.5080700@mow.siemens.ru>
Date: Mon, 11 Jun 2001 22:38:40 +0400
From: Andrej Borsenkow <Andrej.Borsenkow@mow.siemens.ru>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.5-3mdk i686; en-US; rv:0.9.1) Gecko/20010608
X-Accept-Language: en-us
MIME-Version: 1.0
To: zsh-workers@sunsite.dk
Subject: Bugs list
References: <1010611165317.ZM23036@candle.brasslantern.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Bart Schaefer wrote:

>  The known bugs in zsh are listed in the file Etc/BUGS.


This one is gone AFAIK:

When interrupting code like the following with ^C:
   while true; do
     sh -c '...'
   done
if the `sh' is executing, zsh does not know that the sh received a ^C and
continues with the next iteration.  This happens for any program which
handles the interrupt, then exits after tidying up; it does not happen for
zsh, which exits directly from the signal handler.  The workaround is to
use ^Z which forks the shell and makes the loop a separate job, then kill
the suspended loop.


-andrej