zsh-workers
 help / color / mirror / code / Atom feed
From: David Bohman <debohman@gmail.com>
To: zsh-workers@zsh.org
Subject: Re: Ignoreeof warning message regression
Date: Wed, 13 Feb 2019 15:50:55 -0800	[thread overview]
Message-ID: <CAB9xhmN=Dycd86z9ECrF39sc_Cu91a_d7HGwdTG7tqFG0q49ew@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2200 bytes --]

> 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

             reply	other threads:[~2019-02-14 13:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-13 23:50 David Bohman [this message]
     [not found] <CGME20190212174900epcas1p2f71b5f3bafef8ad73a95c1cdb1bf5f8c@epcas1p2.samsung.com>
2019-02-12 17:47 ` David Bohman
2019-02-12 18:34   ` Peter Stephenson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAB9xhmN=Dycd86z9ECrF39sc_Cu91a_d7HGwdTG7tqFG0q49ew@mail.gmail.com' \
    --to=debohman@gmail.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).