From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI,
	RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4
Received: (qmail 18959 invoked from network); 10 Jun 2020 00:54:46 -0000
Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2)
  by inbox.vuxu.org with ESMTPUTF8; 10 Jun 2020 00:54:46 -0000
Received: (qmail 15642 invoked by alias); 10 Jun 2020 00:54:39 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
List-Unsubscribe: <mailto:zsh-workers-unsubscribe@zsh.org>
X-Seq: 46037
Received: (qmail 16801 invoked by uid 1010); 10 Jun 2020 00:54:39 -0000
X-Qmail-Scanner-Diagnostics: from mail-oo1-f41.google.com by f.primenet.com.au (envelope-from <schaefer@brasslantern.com>, uid 7791) with qmail-scanner-2.11 
 (clamdscan: 0.102.3/25835. spamassassin: 3.4.4.  
 Clear:RC:0(209.85.161.41):SA:0(-1.9/5.0):. 
 Processed in 1.651784 secs); 10 Jun 2020 00:54:39 -0000
X-Envelope-From: schaefer@brasslantern.com
X-Qmail-Scanner-Mime-Attachments: |
X-Qmail-Scanner-Zip-Files: |
Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.161.41 as permitted sender)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to;
        bh=1ZqoST+p17OVpi9zwjvibvAYyJFgQ3W1nh8lijoe7lU=;
        b=LgZid0G61gaju5V4XcLavXTck27eg07R7uDEPnDmY/9sajwOBQYbh0KX84AMisAd3C
         tk2gdNoR+/s8droaJ644iZtMtk/e7Q0dwN9dgWnsYivb2rygDau/DMjdeT+j5792WK/d
         fkjSBrfpodG3c+aDtMxs0x1A9JD9oplQ+hMNY2n2jydB9YSXklTvTLeBzhrnoTUhNGQX
         +hooZW5Wv4XMy2+YQDTmpt7yJjFNzgzr2AVeI4RJS7o9q6rs+t+qwHVRSnNf4QbYfMBe
         cfqwe9ytjbz1QVs3jLf7BDyIcR+YV9HEXfyOqu+UKWEoGHVlRnA8wwc5G8IqQZfQ+gJR
         8H4w==
X-Gm-Message-State: AOAM531k1Ya1ADAUCt9IoPnYY35/kCIObnuQoX1rMEOEQw4F7NlW0eES
	JX+9ktPwUKsPXS+5eDqvZXk30yrlbT39wvYdESZv+noojo8=
X-Google-Smtp-Source: ABdhPJz/sIy9EGs36FJVlKmMSFFC+ltuTu0rJifGMyVhIexzlvM3QrUgBgUIe9TIDC/8w5P1i+S0PlgHfyIUUyoNauE=
X-Received: by 2002:a4a:85c3:: with SMTP id u3mr451958ooh.78.1591750442581;
 Tue, 09 Jun 2020 17:54:02 -0700 (PDT)
MIME-Version: 1.0
References: <20200209083316.axjj6nf7hndb7wqw@chazelas.org>
In-Reply-To: <20200209083316.axjj6nf7hndb7wqw@chazelas.org>
From: Bart Schaefer <schaefer@brasslantern.com>
Date: Tue, 9 Jun 2020 17:53:51 -0700
Message-ID: <CAH+w=7Z6E+=aO_05qE0tqMfh1GH3JgHLVk7jbo=JyoqxfScvKg@mail.gmail.com>
Subject: Re: send-break or EOF exit the shell in "vared"
To: Zsh hackers list <zsh-workers@zsh.org>
Content-Type: text/plain; charset="UTF-8"

Happened upon this while reviewing something else ...

On Sun, Feb 9, 2020 at 12:34 AM Stephane Chazelas <stephane@chazelas.org> wrote:
>
> zsh -c 'vared -c foo; echo $? $foo'
>
> If I press ^G (send-break widget), that exits the shell (with
> status 0), not just "vared".
>
> With:
>
> zsh -c '{ vared -c a; } always { TRY_BLOCK_ERROR=0; echo in always; }; echo $? $a'
>
> Upon ^G, the "always" block is run, but that still exits the
> shell (with status 2 this time) despite the TRY_BLOCK_ERROR=0

Looking at this a bit more closely, ^G is treated as an interrupt
here.  This solves the issue:

zsh -c '{ vared -c a; } always {
  TRY_BLOCK_INTERRUPT=0;
  echo in always; }; echo $? $a'

However, an actual interrupt with ^C will still exit the whole shell,
in that specific example.

> zle-line-init() stty -icanon time 10 min 0 <&2
> zle -N zle-line-init
> {
>   vared -c var
> } always {
>   TRY_BLOCK_ERROR=0
>   print in always
> }
> echo "$? $var"

This is an entirely different case.  zle_main.c:getbyte() calls
zexit() directly if raw_getbyte() returns zero.  This is probably a
bug, or it at least should be documented that when ZLE receives EOF it
behaves as if "exit" had been called. IGNORE_EOF will cause it to
retry 20 times, but it never stops getting EOF because the tty has in
fact closed the descriptor.