shandor has asked for the wisdom of the Perl Monks concerning the following question:

I am calling an interactive program from my script that needs the user to type "q" to quit, similar to the UNIX top program. I want the output of the program to go to a file so that I can grab some information from it. 
system ("program_name > $out_file & ");
sleep 5;

setpgrp(0,0);
local $SIG{HUP} = 'IGNORE';
kill (HUP, -$$);

[download]

I am calling the program and outputting it to a file, then sleeping so I can guarantee that the output is getting there (network lag and all). Then, I am setting my script to be the head of the process group with program_name being one of its children. Finally, I am killing all of my scripts children. (The last 3 lines are straight from the Programming Perl book).

This scripts works great from the command line. But, when I have cron run it, the script locks up and is unable to kill the program_name. I think it is the setpgrp(0,0) line that is causing the problem when the script is run as a child of something else, but I don't know how to get around it.

Any suggestions would be well appreciated.

Thanks,

Shandor

Replies are listed 'Best First'.
(tye)Re: killing interactive child processes
by tye (Sage) on Feb 26, 2001 at 21:49 UTC

    cron jobs probably inherit the ignoring of HUP and you'll have to use a different signal for them. INT sounds good to me.

            - tye (but my friends call me "Tye")
[reply]
Re: killing interactive child processes
by Anonymous Monk on Feb 27, 2001 at 00:27 UTC
    I just did something like this recently... If your interactive process reads from STDIN, why not try:

    system("echo q | program_name > $out_file");

    And skip the call to sleep.
    You may even be able to use:

    system("echo | program_name > $out_file");

    since most interactive programs will exit when they read an EOF.

    -rew
[reply]
[d/l]
[select]
[reply]
[d/l]

Back to Seekers of Perl Wisdom