Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Ignoreeof warning message regression
- X-seq: zsh-workers 44063
- From: Peter Stephenson <p.stephenson@xxxxxxxxxxx>
- To: <zsh-workers@xxxxxxx>
- Subject: Re: Ignoreeof warning message regression
- Date: Tue, 12 Feb 2019 18:34:57 +0000
- Cms-type: 201P
- Dkim-filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20190212183500euoutp014b839edd69baa2256e20ac894ca4d48a~CsZr8Heuq0528705287euoutp01x
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1549996501; bh=14y6DhlTsOWBDTh7GYQhetac+qGHyLqbNaNtj2FCxTQ=; h=Subject:From:To:Date:In-Reply-To:References:From; b=WCglpIS5zNuf7oPCfG8BAWdO+eJ/AbTtONSMO+2IiSHEf94MECu8zBFGRj2Cncn8g ewCFekLiBIQphTaKzsB9SlYQfHvU32T1XLPTr7kj+a2sVgRRqapyIm6ud1rMUTlVt9 nP4ckTPoxSnv5Y4FuIIcf5QEXhISvLruq4DYNyIQ=
- In-reply-to: <CAB9xhmNUw05v5cvkzBvWj+JSCnksEe_jRApdwgHB296TnYgugA@mail.gmail.com>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- List-unsubscribe: <mailto:zsh-workers-unsubscribe@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <CGME20190212174900epcas1p2f71b5f3bafef8ad73a95c1cdb1bf5f8c@epcas1p2.samsung.com> <CAB9xhmNUw05v5cvkzBvWj+JSCnksEe_jRApdwgHB296TnYgugA@mail.gmail.com>
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
Messages sorted by:
Reverse Date,
Date,
Thread,
Author