Re: [BUG] Ctrl-C stops working after process substitution

[Peter Stephenson <p.stephenson@xxxxxxxxxxx>]

On Wed, 4 Jul 2018 19:07:17 +0200
Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx> wrote:
> On 4 July 2018 at 14:09, Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:

> > Works for me in master.  
> 
> True, here is code that yields Ctrl-C problem even in zsh -f:
> 
> For zsh -f:
> 
> noop() { IFS='' read line; MYFD="$1"; zle -F "$1"; exec {MYFD}<&-; };
> exec {MYFD}< <( echo a test ); zle -F -w $MYFD noop
> 
> After executing, try Up cursor to obtain some command at prompt (or
> just enter "abcd") and press Ctrl-C. First will be ignored, second one
> will work. This differs from non-zsh-f behavior where any Ctrl-C will
> be ignored. However in zsh -f situation, what's very interesting is
> that the second-Ctrl-C behavior occurs for any number of following
> commands.

My first guess about this is that it's to do with propagation
of errors and interrupts back from the widget.

The -F handling is in the loops beginning

		for (i = 0; i < lnwatch; i++) {

in zle_main.c.  At the end there's a check for errflag and if
it's set the error bit ERRFLAG_ERROR is removed and we ignore that
FD until the read function returns.  There could be something
unhelpful in this area.  In particular we don't do anything with
the interrupt bit ERRFLAG_INT or a hard error ERRFLAG_HARD.

But that's just a guess.

pws