Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: process substitution and Ctrl-C
- X-seq: zsh-users 15299
- From: Peter Stephenson <Peter.Stephenson@xxxxxxx>
- To: zsh-users@xxxxxxx
- Subject: Re: process substitution and Ctrl-C
- Date: Thu, 19 Aug 2010 18:15:56 +0100
- In-reply-to: <20100819140730.70daeb3b@xxxxxxx>
- List-help: <mailto:zsh-users-help@zsh.org>
- List-id: Zsh Users List <zsh-users.zsh.org>
- List-post: <mailto:zsh-users@zsh.org>
- Mailing-list: contact zsh-users-help@xxxxxxx; run by ezmlm
- Organization: Cambridge Silicon Radio
- References: <20100819124142.GQ16075@xxxxxxxxxxxxxxxxxxx> <20100819140730.70daeb3b@xxxxxxx>
On Thu, 19 Aug 2010 14:07:30 +0100
Peter Stephenson <Peter.Stephenson@xxxxxxx> wrote:
> On Thu, 19 Aug 2010 14:41:42 +0200
> Vincent Lefevre <vincent@xxxxxxxxxx> wrote:
> > In the following example:
> >
> > { repeat 10 { date >&2; /bin/sleep 1 } } 2>>(cat -n; loop)
> >
> > where "loop" is a program that consumes CPU time, is it normal that
> > when one interrupts the command with Ctrl-C, the substituted process
> > isn't killed? (I can see "loop" taking CPU time.)
>
> Without looking at the code, I wouldn't be at all surprised: unless
> we did something special, SIGINT would go only to foreground
> processes, which wouldn't include the process substitution.
> Logically, you might have thought that passing the SIGINT as received
> by the shell on to associated processes (which are recorded in a part
> of the job record) should be possible, but this sort of thing is
> fairly well down my personal list of priorities.
I managed to get to the point where I had zero time to spare. That's up
significantly from the usual amount, so I looked at this.
In fact we're jumping through a fairly large and stable hoop not all that
far above the ground to behave as if "we" got SIGINT. "We" here is just
the main shell. You might think, logically, that any process attached to
any job marked as running in the current shell should also get the signal
passed, if we're going to maintain the fiction. This is a slightly smaller
hoop held a little further over the ground, but I don't see any fundamental
reason why we shouldn't jump through it. Anyway, the following seems to do
the trick here.
Index: Src/jobs.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/jobs.c,v
retrieving revision 1.78
diff -p -u -r1.78 jobs.c
--- Src/jobs.c 18 Aug 2010 21:21:17 -0000 1.78
+++ Src/jobs.c 19 Aug 2010 17:08:33 -0000
@@ -496,6 +496,27 @@ update_job(Job jn)
breaks = loops;
errflag = 1;
}
+ if (errflag) {
+ /*
+ * As we're pretending we got the signal, we need to
+ * pretend anything attached to a CURSH process
+ * got it, too.
+ */
+ int i, j;
+ for (i = 1; i <= maxjob; i++) {
+ if ((jobtab[i].stat & (STAT_CURSH|STAT_DONE)) ==
+ STAT_CURSH) {
+ for (j = 0; j < 2; j++) {
+ pn = j ? jobtab[i].auxprocs : jobtab[i].procs;
+ for (; pn; pn = pn->next) {
+ if (pn->status == SP_RUNNING) {
+ kill(pn->pid, sig);
+ }
+ }
+ }
+ }
+ }
+ }
}
}
}
--
Peter Stephenson <pws@xxxxxxx> Software Engineer
Tel: +44 (0)1223 692070 Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
Messages sorted by:
Reverse Date,
Date,
Thread,
Author