develooper Front page | perl.perl5.porters | Postings from September 2013

Re: [perl #92246] Perl 5.14 does not allow "internal" setting of $ENV{'PERL_SIGNALS'}

Thread Previous
Leon Timmermans
September 10, 2013 20:55
Re: [perl #92246] Perl 5.14 does not allow "internal" setting of $ENV{'PERL_SIGNALS'}
Message ID:
On Sat, Sep 7, 2013 at 4:49 AM, Cameron Kaiser <> wrote:

> I never received Leon's request. The difference in behaviour relates to
> real-time signal handling; if a system call is running, it may not be
> interrupted by a signal coming through. I could write up a script to bang
> on a second process if you like to show the difference. The specific
> application that went awry was TTYtter (and Texapp, its descendent) when
> using a ReadLine driver; the ReadLine driver would send signals to TTYtter
> to squelch it while the user was typing and only with 'unsafe' signals on
> would the select() be reliably interrupted.

I can imagine running in such issues when using a XS module that don't
respect Perl's signaling system, not in a pure-perl application (Which
Texapp seems to be unless you've explicitly loaded Gnu Readline or some

So yes, I would be most interested in a *short* example of this problem,
because this is either a bug in your code or in ours. Texapp is a 268kb,
7400SLOC script that doesn't even use strict. There's no way anyone is
going to debug that.

> However, I suspect that there is no interest in restoring the prior
> behaviour (as evidenced by this particular reply), so I've started
> requiring
> users to either set this variable before starting the script, or have a
> full
> installation with It's suboptimal, but it works.
> I would be happy to try to fix this myself, if there is any interest in
> accepting a patch.

I don't think the old behavior should be restored, but one could argue the
unsafeness should have been exposed using some magical variable.


Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About