From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 745bf9b2 for ; Thu, 14 Feb 2019 13:17:58 +0000 (UTC) Received: (qmail 20393 invoked by alias); 13 Feb 2019 23:51:13 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 44066 Received: (qmail 21029 invoked by uid 1010); 13 Feb 2019 23:51:13 -0000 X-Qmail-Scanner-Diagnostics: from mail-lf1-f65.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.100.2/25112. spamassassin: 3.4.2. Clear:RC:0(209.85.167.65):SA:0(-2.0/5.0):. Processed in 1.654218 secs); 13 Feb 2019 23:51:13 -0000 X-Envelope-From: debohman@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=XuJm1uOGT2wydZkqwgfdjGIx6p3txDGxoVmL84RhW58=; b=CB1DsAf/fNICaajxTkBdGRNInxBStsXL5PbgN3CNJRp4gNi16K+qNAXg/3vy9ugTp1 GMHCwst/GsYrDIe5nuJkgC8sEI6hlDS/xJiynEFCHowVbf5TTZRtlBtxJZZj3ak25jA4 nvYUOjEu0uxKGrTbYvEHOPk3wszNtfE8F7f+TqDKiDJbBMPdTfkscQa+uzGp073cdHnu u+yNDGhNlLjRNJSVd1t8RqOL9Vqze12+IRKr9rScwNcmxiDa7YtzBiye8TkcqmzHj3af 8M7fAmHf1QFsN6KkgYizcLSqI3W/E/oG76o9j3ptI7yACaHrxvQpEh2yME6sVrPxQorI fYBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XuJm1uOGT2wydZkqwgfdjGIx6p3txDGxoVmL84RhW58=; b=Y4bBJEQ/lpOUcd+FqSPkyrbOyHe+IcqmzY64DOXAPBnIw2CE6Sj1C46B3sPAq/LImK ChThlFs0BSV60/XVp/dFPp2ItrACedSHxkXX/s1H1Q/QsUuymZVtJIccyqR9P0cy9YNT kc/NJkhX5v9OCEhXdlC5H2ZRjUTVUy/7wwNqJAEmxUQ2jvkOp+91ZBKD/ZyVpnhHaWU7 RLeVd2AQYBqaLhPKbV0DQeC/zXZ25sCJxM6VN3EWyiTNBqSJ/pjgOS/7kMIiUCjOXpnQ DPFA9eiOgBxlbg+/DEFS+IUGww/kANId/7qyNGB/SYQLvAXwF5JnuvXU9kJxpDv7CQrh Rnyw== X-Gm-Message-State: AHQUAuaEsT8tXwGYOzSLX10Hz/x97KUouWNgNeUp23KLenVl2Cv+cK/3 w777PWagpWIvC/9lKr772oV58GiNqqicGvZNYD0o+A== X-Google-Smtp-Source: AHgI3IYJ1WjwiEuQboNEy+7X7hY0LztQu1wTPgIjLYpL3dG41FJzAbRWvTJVFZqNJuXufP5pRrkh0dcuZ3bGKxuMbhg= X-Received: by 2002:ac2:4215:: with SMTP id y21mr496827lfh.6.1550101866808; Wed, 13 Feb 2019 15:51:06 -0800 (PST) MIME-Version: 1.0 From: David Bohman Date: Wed, 13 Feb 2019 15:50:55 -0800 Message-ID: Subject: Re: Ignoreeof warning message regression To: zsh-workers@zsh.org Content-Type: multipart/alternative; boundary="00000000000023095e0581cf3756" --00000000000023095e0581cf3756 Content-Type: text/plain; charset="UTF-8" > On Tue, 2019-02-12 at 09:47 -0800, David Bohman wrote: > > This is an old regression, which apparently occurred between release 5.3.1 > > and 5.4 of zsh. > > > > If you have the ignoreeof option set, and type a CTL-D to the shell, you > > are supposed to get a warning message: > > > > zsh: use 'exit' to exit. > > > > Instead, a blank line is emitted. This was introduced by > > commit 34656ec2f00d6669cef56afdbffdd90639d7b465, specifically the change to > > Src/Zle/zle_main.c. > > > > The problem occurs both on Ubuntu 18.04.1 running zsh 5.4.2 and macOS > > 10.12.6 running 5.4 forwards to 5.7.1. Stock macOS 10.12.6 contains zsh 5.2 > > and does not manifest the bug. > > > > The problem disappears when the change to Src/Zle/zle_main.c is backed out. > > Yes. In this case we do need to remember the state of the command line > when we return to ZLE after passing nothing-very-much back to the main > shell --- the ^D was ignored but we told the main shell about it anyway, > then came back into ZLE expecting to pick up exactly where we left off, > meaning we shouldn't clear the message we printed and that the main > shell we briefly returned to knows nothing about... It's not at all > clear that's sensible behaviour but refactoring the states of ZLE is > probably beyond anyone's capabilities at this point. > The original fix is here (zsh-workers/40305): > http://www.zsh.org/mla/workers/2017/msg00053.html > I'm not sure the change to zle_main.c there is the key one for the fix > as a whole --- backing it off doesn't appear to make the specific > problem (not the originally reported one in that thread) being addressed > there fail, and it may be the associated change to clearflag in > zle_refresh.c was the key one. > However, as there were various related issues associated with > asynchrohonous behaviour, it's hard to be sure. > In the absence of a test suite for this sort of not only interactive but > asynchronous behaviour (zpty is way out of its depth here), I'm tempted > to make that change and see what happens. > pws Thanks. I'll admit that I am not familiar with the code. I have installed the patched version on my system, and it seems to be running fine. David --00000000000023095e0581cf3756--