Skip Menu |
 
Update: The rt.cpan.org bug tracker service is no longer shutting down.

This queue is for tickets about the IO-Prompt CPAN distribution.

Report information
The Basics
Id: 32799
Status: new
Priority: 0/
Queue: IO-Prompt

People
Owner: Nobody in particular
Requestors: vincenzo [...] daniele-online.de
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



CC: sabine [...] daniele-online.de
Subject: Request for IO::Prompt
Date: Wed, 30 Jan 2008 15:18:27 +0100 (CET)
To: bug-io-prompt [...] rt.cpan.org
From: "Vincenzo" <vincenzo [...] daniele-online.de>
Hello Mr. Conway and other developers of IO::Prompt, first of all, thanks for that great module, it already helped a lot. Now I found one difficulty with it. I set up a program that I like to cope with some signals, especially catching ctrl-c. So I wrote: $SIG{'INT'} = \&got_int; ... and later sub got_int { # clean up some things here ... die "Received INT -> Going out now\n"; }; But (only) while prompting, it does not work (my got_int does not run), because prompt comes with its own signal handling in _fake_from_DATA: sub _fake_from_DATA { my ($caller, $IN, $OUT, $flags, @prompt) = @_; local $SIG{INT} = sub { ReadMode 'restore', $IN; exit }; .... That ruins completely my own signal ambitions :-) At the moment, I do not know how to circumvent this. Is there maybe a way to get around this by something else you can show me? Or is there a chance that you can do something about it? Maybe a flag, that skips that signal handling, so that I can do my own stuff? Thank you very much in advance, Vincenzo Daniele


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.