From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28817 invoked by alias); 7 Jul 2018 14:48:33 -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: 43148 Received: (qmail 14342 invoked by uid 1010); 7 Jul 2018 14:48:33 -0000 X-Qmail-Scanner-Diagnostics: from mail-oi0-f44.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.218.44):SA:0(-1.9/5.0):. Processed in 1.47393 secs); 07 Jul 2018 14:48:33 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_PASS,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: sgniazdowski@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:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=r5mb42IQ2AP9HNp/9jbAC7qT+ufBBJaxLSCpmXaHOp8=; b=JP9lIUmIVSnALqbtPcqC/6e+j7AWHpH0Mbilgv9Pb2mi1HDae6KRbrFLvgvfm81trY bpgise9AxZQqHxCbpT0mhzlgW10s3O9qmUfvxKjci3sA1w6KSsfBCBF9cwOypbJKps8W qO11P9n29sVMwsTESeRhyV5Qfb2M6fJEBxPIDUeFwx3B8dMTvPZpaMlx9vBRzmMwPoVq UeY3bw6yMTXFtqyymK8Xeqog3Zv3Xb+k7l/t+fap664F0bfJd7s1wHw24SbnAPghvgXl zFa0KFtY7jYPAOFD6NVY1T6cmnU3UqczEGupJ5Y9GtZlqdlSWyzAYEpCVaCicSCgGY6Q WADA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=r5mb42IQ2AP9HNp/9jbAC7qT+ufBBJaxLSCpmXaHOp8=; b=tgBMk+HWnXYFl5wXPajXQl0FdJQnRIaoAodhNlVncHvQXp8SNqbNNrVdHYgbcyc++D 6O+nl0cF2HftwrkmHmXeNTXaxYZski1e/y5/8TK/K33U/EOQ7dDKBs9xGGMDe6MYdpoz Qdzuv5684xCz/W2GxWjLPlxz6LKpslPyONiCWCMQWy0YM4QVMGsD9cc6MXv4ThGOa2DV sE3fsyupZ5Kls0W7wrvqpV3tvG7gnYGlurTPUdCa7hlS+UVOY5Vs3c4UH0LMlBub+fKh bKEIan/S3NkBPmgp38/3+hmgCW2+PUipKITe4fmMW7MPkO5lJFI2G+iOe+uDfNelr2ju HF8w== X-Gm-Message-State: APt69E3xk4GGsfUb5KAb8Wa008z5qRwfQJ4IOxsgqIgfMGsk9jcuys2X /uwEHFg8C3zkq2uszo6URwo/VR2Dk8PaxUwUv0Y= X-Google-Smtp-Source: AAOMgpf2ORrTh2Y9KHaAQblwfqpOFN04ZIO7+ElJUE2+9UdLvgf/1XyHk+Pevx59xZ31UzedbfkfyETV/sX46yQi2xc= X-Received: by 2002:aca:ce85:: with SMTP id e127-v6mr16552516oig.169.1530974909810; Sat, 07 Jul 2018 07:48:29 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20180705084448eucas1p244dbcec9f6d915655cd8bb035fb72f6e~_bI-T7ynp0198101981eucas1p2S@eucas1p2.samsung.com> References: <1530706152.948208.1429754600.66E3F94F@webmail.messagingengine.com> <20180705084448eucas1p244dbcec9f6d915655cd8bb035fb72f6e~_bI-T7ynp0198101981eucas1p2S@eucas1p2.samsung.com> From: Sebastian Gniazdowski Date: Sat, 7 Jul 2018 16:48:09 +0200 Message-ID: Subject: Re: [BUG] Ctrl-C stops working after process substitution To: Peter Stephenson Cc: Zsh hackers list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 5 July 2018 at 10:44, Peter Stephenson wrote: 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. I have an observation. I configure LLDB to pass SIGINT to program. LLDB shows this table: NAME PASS STOP NOTIFY =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D =3D=3D= =3D=3D=3D=3D SIGINT true true true So on Ctrl-C, it will be passed to program and program will be stopped (i.e. debugger will stop program to allow stepping, etc.). I then attach to proper PID of a Zsh instance. Then press Ctrl-C =E2=80=93 debugger activates, Zsh obtains signal. Ok. Then I paste some text into Zsh so that Fast Syntax Highlighting runs zle -F -w handlers that check if string is a path (to highlight this string). So far so good. Then I press Ctrl-C and (IMPORTANT) =E2=80=93 nothing happe= ns. Even debugger doesn't activate. I can press Ctrl-C many times. Pasting text that runs zle -F -w stuff leaves Zsh and debugger blind to Ctrl-C. Isn't this a masking of interrupt? This would explain the main problem =E2=80=93 no reaction to Ctrl-C. If I then use the known method to dig-out from this improper state =E2=80= =93 Ctrl-D, then Ctrl-C starts working again =E2=80=93 debugger notices it and activates, program obtains it (zhandler is called). So what could mask SIGINT as the result of pasting text and zle -F -w invocation? There's a hint: pasting the text into command line causes zhandler invocations (I have breakpoint in zhandler). I paste string "NAME" (header of the table) =E2=80=93 nothing happens. Press space, then paste "NAME" again =E2=80=93 now Fast Syntax Highlighting will run zle -F -= w because "NAME" occurs as program argument, and can potentially be a path. Effect: two zhandler calls: frame #0: 0x000000010f8517d2 zsh`zhandler(sig=3D20) at signals.c:601 -> 601 last_signal =3D sig; 602 signal_process(sig); sig =3D=3D 20, then some stuff is executed that isn't clear for me yet. What can be happening? SIGINT (?) reaching zhandler two times, just because I pasted text that ran zle -F -w? I then go final minimal thing: start zsh -f and run: noop() { print "I'm ran" >> /tmp/reply; IFS=3D'' read line; MYFD=3D"$1"; zle -F "$1"; exec {MYFD}<&-; }; exec {MYFD}< <( echo a test ); attach() { zle -F -w $MYFD noop; }; zle -N noop; attach And =E2=80=93 zhandler is called! It's pure-empty, clear Zshell, no fast-syntax-highlighting, so just pasting doesn't yield any debugger reaction. But running it calls zhandler (sig=3D=3D20) two times. I then minimize further: exec {MYFD}< <( echo a test ) This code starts zhandler 1 time (sig=3D=3D20). So my conclusion is: exec and/or <() invoke zdhandler in such a way, that it masks SIGINT. That said, full Zsh with Fast-Syntax-Highlighting is needed for the effect of Ctrl-C blockage to occur, in zsh -f I can repeat zhandler invocations, but Ctrl-C still works. --=20 Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin