zsh-workers
 help / color / mirror / code / Atom feed
From: Dima Kogan <dima@secretsauce.net>
To: zsh-workers <zsh-workers@zsh.org>
Subject: Possible bug in signal handling
Date: Mon, 02 Nov 2015 02:10:24 -0800	[thread overview]
Message-ID: <87wpu0g19r.fsf@secretsauce.net> (raw)

Hi. I'm seeing a suspicious behavior in zsh that isn't present in bash
or dash. I'm not 100% sure the way this is supposed to work, so maybe
zsh is still correct here, but filing this report just in case.

The behavior is concerned with the user invoking a pipeline in zsh, then
hitting Ctrl-C to kill it. One of the processes in the pipeline
overrides SIGINT to ignore the first Ctrl-C; I would expect all the
processes in the pipeline to die at the first Ctrl-C, except the
overriding process. I would expect zsh to recognize the one still-alive
process, and to not put up another prompt. When the user hits Ctrl-C a
second time, the overriding process dies in response, and zsh should
detect this, and prompt for a new command. This does happen most of the
time in zsh, but I'm hitting a case where it doesn't:

I have a /tmp/tst.sh script:

   awk '{print; fflush()}' | \
       perl -e 'BEGIN { $SIG{INT} = sub { $SIG{INT} = undef; }; } while(<>) {sleep 1;} sleep 10000;'

This script has a pass-through awk feeding a perl command that overrides
SIGINT, and ignores the first SIGINT that comes in.

I invoke this script thusly:

$ seq 5000 | perl -nE 'say "xxx"; sleep(1)' | zsh /tmp/tst.sh

So it's a mostly do-nothing pipeline. When the user hits Ctrl-C the
first time, I expect everything but the inner zsh and the inner perl
processes to die, and the outer zsh to NOT display another prompt until
a second Ctrl-C. Instead I see everything except the inner perl die
(inner zsh dies too), and the prompt is returned immediately. This
effectively disowns the inner perl, so it cannot be killed
interactively.

If I replace the inner zsh with bash or dash, things work the way I
expect. Things also work the way I expect if I get rid of the awk or if
I get rid of the inner zsh, putting the whole pipeline on the
commandline.

Is this a zsh bug? If not a bug, can this be made to work the way I
expect it to?

Thanks! This is a bit convoluted, but hopefully it was clear enough.

dima


             reply	other threads:[~2015-11-02 10:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-02 10:10 Dima Kogan [this message]
2015-11-04  4:16 ` Bart Schaefer
2015-11-04  4:27   ` Dima Kogan
2015-11-04  4:46     ` Bart Schaefer
2015-11-04 14:25       ` Vincent Lefevre
2015-11-04 19:01         ` Bart Schaefer

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=87wpu0g19r.fsf@secretsauce.net \
    --to=dima@secretsauce.net \
    --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).