>>>>> "AS" == Aaron Sherman <[EMAIL PROTECTED]> writes:
AS> On Tue, 2005-01-25 at 11:34, Uri Guttman wrote:
>> >>>>> "GL" == Greg London <[EMAIL PROTECTED]> writes:
GL> After the system call, how do I test for a control-c
GL> as the cause for the command ending?
>>
>> look at $@ and check for why the process died. you can extract a signal
>> number from it (shift 8 bits and mask IIRC, rtfm for details. i think
>> perlvar covers it).
AS> This is incorrect. $@ is for eval, $? is for system.
yep. more sleep is needed. and p6 fixes this odd inconsistancy too.
>> just check for SIGINT and handle that.
AS> You're correct, but that's not clear to the uninitiated. Here's the
AS> explanation:
AS> $? contains the exit status of the program. On POSIX-compliant systems
AS> this is a number which is:
AS> ($exit << 8) | $signal
AS> Where $exit is the parameter that the program passed to exit(2), and
AS> $signal is the signal that interrupted the process, if any.
if i was more awake i would have expounded like this. :)
AS> You can check to see if the process was killed by:
AS> if ($? & 0xff) {
AS> die "Process killed by signal ".($? & 0xff);
AS> } elsif ($? >> 8) {
AS> die "Process exited with status ".($? >> 8);
AS> } else {
AS> # Worked fine
AS> }
AS> Make sense?
AS> This is also a faq, so you can type:
AS> perldoc -q control-c
AS> to see what the lord of the FAQ says ;-)
i was right about rtfm! :)
uri
--
Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
_______________________________________________
Boston-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/boston-pm
