in reply to Testing for a background process waiting for input

Just a thought. Here is a basic example of running the 'bc' calculator and collecting the STDOUT and STDERR separately. So, you could drop in your program, and watch the STDOUT and STDERR streams for your special prompt, then play a sound or ring the bell, or whatever, even automatically write to STDIN if the special user prompt is seen. This script could be put into the background by running it with an &, like ./myscript &
#!/usr/bin/perl use warnings; use strict; use IPC::Open3; use IO::Select; #interface to "bc" calculator my $pid = open3(\*WRITE, \*READ,\*ERROR,"bc"); #if \*ERROR is false, STDERR is sent to STDOUT my $selread = new IO::Select(); my $selerror = new IO::Select(); $selread->add(\*READ); $selerror->add(\*ERROR); # may not be best use of IO::Select, but it works :-) my($error,$answer)=('',''); while(1){ print "Enter expression for bc, i.e. 2 + 2\n"; chomp(my $query = <STDIN>); #send query to bc print WRITE "$query\n"; #timing delay needed tp let bc output select(undef,undef,undef,.01); #see which filehandles have output if($selread->can_read(0)){print "ready->read\n"} if($selerror->can_read(0)){print "ready->error\n"} #get any error from bc sysread(ERROR,$error,4096) if $selerror->can_read(0); if($error){print "\e[1;31m ERROR-> $error \e[0m \n"} #get the answer from bc sysread(READ,$answer,4096) if $selread->can_read(0); if($answer){print "$query = $answer\n"} ($error,$answer)=('',''); } waitpid($pid, 1); # It is important to waitpid on your child process, # otherwise zombies could be created.

I'm not really a human, but I play one on earth.
Old Perl Programmer Haiku ................... flash japh

Replies are listed 'Best First'.
Re^2: Testing for a background process waiting for input
by SBECK (Chaplain) on Apr 13, 2012 at 19:51 UTC

    This depends on knowing what the prompt will be, which I don't in this case. If I know what the prompt would be, of course I can just wait until I see it, but in this case I don't know what it'll be.

    I actually know what to do IF the program is waiting for input. What I need to be able to do is distinguish whether the background program is running (and just taking a while to complete) or if it's stalled waiting for input.

    In this situation, it's actually not critical that I be able to interact with the program... I just need to know what state it's in. That's why it's not absolutely critical that I use IPC::Open3 or RPC::Run... if I can have access to STDIN/STDOUT, that would be nice, but I'll do without if I have to.

    One more detail... the program will be sending stuff to STDOUT/STDERR, so the presense of output from the program doesn't signal that it's prompting for input.