After doing a fork and executing a shell, we execute (third party) commands which are essentially non-interactive. But some of them ask for input, under some (unforeseeable) circumstances. When this happens we go on waiting for output. Their is timeout, of course, but we don't seem to know if the process is actually doing some processing or is just simply waiting on us. Just wanted to ask if it is possible by some trickstery to find is the command is waiting for input. Note we can't parse the command output to check if it is waiting on input, because it varies across commands and becomes unmaintainable.
One possible approach that I can think of is looking out if the process is waiting on the stdin file descriptor. Could somebody elaborate as to how do I proceed in this direction.
Your forking parent should fetch its children from the proc table.
If it's a mere shell script it could call wait [pid].
If it's a program or script written in an IPC capable language
you should call waitpid(). Usually one would implement a signal handler
that automatically fetches its children exit codes on SIGCHLD within a loop or so.
To see whether your child is expecting input from stdin you could for instance strace or tusc by attaching to its PID and watch the syscalls.
Could you elaborate on the strace or tusc part. As per my understanding they are unix commands, however I need to do something programmatically because we are doing a C fork in calling the command. Further this needs to be as efficient as possible because, as far as I can understand this would require polling, unless there is some way to signal the parent process that child is waiting on the input. Note that we have no control on the child process, in a sense that we can't change is to send the signal or anything (they are external binaries).
