On Tue May 22 21:42:23 2012, dmcbride@cpan.org wrote: > Because sometimes a patch spurs more conversation than, well, more > conversation... this is on 5.17.0 blead. > > This seems to resolve (a): "kill -INT=>$$" gives a funny return code > now, no complaints about numbers even under warnings. It takes Leon's > suggestion for (c) (no more killpg(2)). It explicitly marks (b) as > "undefined" in the docs without (I believe) changing behaviour. I think all that is a good idea. > It also > completely and utterly fails to address (d): adding appropriate tests. But for your patch to be applied, we need tests at least for the behaviour it is changing. Tests for other untested aspects of kill are nice, but not necessary to get this patch in. I do have a couple of observations, though: @@ -1682,6 +1683,12 @@ nothing in the core. if (mark == sp) break; s = SvPVx_const(*++mark, len); + if (isALPHA(s[1]) && *s == '-') + { + s++; + len--; + killgp = true; + } if (isALPHA(*s)) { if (*s == 'S' && s[1] == 'I' && s[2] == 'G') { s += 3; Why not put the if(*s == '-') inside the existing if(isALPHA) alpha, as a nested if()? That way isALPHA is only checked once. the operating system. For example, on POSIX-conforming systems, zero will -signal the current process group and -1 will signal all processes. +signal the current process group and -1 will signal all processes, and any +other negative PROCESS number will act as a negative signal number and +kill the entire process group specified. I would suggest s/group and -1/group, -1/. -- Father Chrysostomos --- via perlbug: queue: perl5 status: open https://rt.perl.org:443/rt3/Ticket/Display.html?id=112990Thread Previous