Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: [BUG] Ctrl-C stops working after process substitution
- X-seq: zsh-workers 43146
- From: Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>
- To: Peter Stephenson <p.stephenson@xxxxxxxxxxx>
- Subject: Re: [BUG] Ctrl-C stops working after process substitution
- Date: Sat, 7 Jul 2018 15:03:13 +0200
- Cc: Zsh hackers list <zsh-workers@xxxxxxx>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Cau8X6pbKbWWzRRg0Y9uJHyjbpyUk9HaN8r6WXizgtI=; b=gF4DflIbVA87z6UMyedWwViSXeZaiadFBmID/FbClHBZ+ZhO5r6vEd7RQ4z64FGRTa //MVd9y10U6GW5p+SFfe3ioE5IxRQ1X1i+DixP3mX+gzwQhJK4fP8gPk6BSmcMsQI7RT rCB3rZE2a4D5T0bV0E7MBDroHI4kxtmrZa09WGyvJX2LnvD9l+tn4T8iIvJC65EEnqfp 2Yr8Mi1f1kcazyBF5GIsZOkxBridEdbF8NlHBiH+BhFuX99CQPztdTT813UQsw3c/QAi 2qlFduIec3Fr2g+PNf35ojiwOLIN3KBKB6EILXCAv71PGSEebtldQkiMHikhEBbz5F8A Dp+Q==
- In-reply-to: <20180705084448eucas1p244dbcec9f6d915655cd8bb035fb72f6e~_bI-T7ynp0198101981eucas1p2S@eucas1p2.samsung.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: <CAKc7PVAkph0UJGRojp3+H2VVYOHWsTCLQo9iONh0TnuvMwL_=Q@mail.gmail.com> <1530706152.948208.1429754600.66E3F94F@webmail.messagingengine.com> <CGME20180704170810epcas5p29840028fd34c40ae2a91008f8c25eb79@epcas5p2.samsung.com> <CAKc7PVB5fd-aqgFeuTTpBU9TYUkAfcVT1+PmCGmMFJEij2azVw@mail.gmail.com> <20180705084448eucas1p244dbcec9f6d915655cd8bb035fb72f6e~_bI-T7ynp0198101981eucas1p2S@eucas1p2.samsung.com>
On 5 July 2018 at 10:44, Peter Stephenson <p.stephenson@xxxxxxxxxxx> wrote:
> 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.
I'm trying to debug it now. I noted, that the handler (noop) isn't
run. Tried to attach from within Zle:
noop() { print "I'm ran" >> /tmp/reply; IFS='' read line; MYFD="$1";
zle -F "$1"; exec {MYFD}<&-; };
exec {MYFD}< <( sleep 2; echo a test ); attach() { zle -F -w $MYFD
noop; }; zle -N attach; bindkey '^T' attach
But still cannot see the `print' message in /tmp/reply. This is weird
as this works from bigger script, maybe there's a mistake?
--
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Messages sorted by:
Reverse Date,
Date,
Thread,
Author