Shell – How to periodically check if STDIN is open

file-descriptorsshell

Some programs will exit when their STDIN is closed. Those that do this work nicely with Erlang/Elixir supervision via "ports".

For those that don't, the Elixir docs suggest this wrapper script:

#!/bin/bash
# wrapper.sh
"$@" &
pid=$!
while read line ; do
  :
done
kill -KILL $pid

This allows calling wrapper.sh my_script arg1 arg2. wrapper.sh starts and backgrounds the specified program, and when wrapper.sh's STDIN is closed, its blocking read finishes and it terminates the backgrounded process.

This approach has a downside, however; if the backgrounded process terminates for some other reason, wrapper.sh doesn't notice, and therefore neither does Erlang/Elixir.

I'd like to modify this script to do the following:

In a loop:

If STDIN is closed, kill $pid
If $pid is dead, exit
Otherwise, sleep briefly

Can anyone suggest a way to do this?

Best Answer

You can check if $pid is dead like so:

while kill -0 $pid >/dev/null; do
    # $pid is still alive
done

# $pid is dead or you lack permissions to send signals to it

Related Solutions

What sets a child’s STDERR, STDOUT, and STDIN

Stdin, stdout and stderr are inherited from the parent process. It's up to the child process to change them to point to new files if that is needed.

From the fork(2) man page:

   *  The  child inherits copies of the parent's set of open file descrip‐
      tors.  Each file descriptor in the child refers  to  the  same  open
      file  description (see open(2)) as the corresponding file descriptor
      in the parent.

Shell – How to forward between processes with named pipes

If you get rid of the killing and shutdown stuff (which is unsafe and you may, in an extreme, but not unfathomable case when child.py dies before the (head -n 1 shutdown; kill -9 $parent) & subshell does end up kill -9ing some innocent process), then child.py won't be terminating because your parent.py isn't behaving like a good UNIX citizen.

The cat std_out & subprocess will have finished by the time you send the quit message, because the writer to std_out is child_original.py, which finishes upon receiving quit at which moment it closes its stdout, which is the std_out pipe and that close will make the cat subprocess finish.

The cat > std_in isn't finishing because it's reading from a pipe originating in the parent.py process and the parent.py process didn't bother to close that pipe. If it did, cat > stdin_in and consequently the whole child.py would finish by itself and you wouldn't need the shutdown pipe or the killing part (killing a process that isn't your child on UNIX is always a potential security hole if a race condition caused due to rapid PID recycling should occur).

Processes at the right end of a pipeline generally only finish once they're done reading their stdin, but since you're not closing that (child.stdin), you're implicitly telling the child process "wait, I have more input for you" and then you go kill it because it does wait for more input from you as it should.

In short, make parent.py behave reasonably:

from __future__ import print_function
from subprocess import Popen, PIPE
import os

child = Popen('./child.py', stdin=PIPE, stdout=PIPE)

for letter in 'abcde':
    print('Parent writes to child: ', letter)
    child.stdin.write(letter+'\n')
    child.stdin.flush()
    response = child.stdout.readline()
    print('Response from the child:', response)
    assert response.rstrip() == letter.upper(), 'Wrong response'

child.stdin.write('quit\n')
child.stdin.flush()
child.stdin.close()
print('Waiting for the child to terminate...')
child.wait()
print('Done!')

And your child.py can be as simple as

#!/bin/sh
cat std_out &
cat > std_in
wait #basically to assert that cat std_out has finished at this point

(Note that I got rid of that fd dup calls because otherwise you'd need to close both child.stdin and the child_stdin duplicate).

Since parent.py operates in line-oriented fashion, gnu cat is unbuffered (as mikeserv pointed out) and child_original.py operates in a line oriented fashion, you've effectively got the whole thing line-buffered.

Note on Cat: Unbufferred might not be the luckiest term, as gnu cat does use a buffer. What it doesn't do is try to get the whole buffer full before writing things out (unlike stdio). Basically it makes read requests to the os for a specific size (its buffer size), and writes whatever it receives without waiting to get a whole line or the whole buffer. (read(2) can be lazy and give you only what it can give you at the moment rather than the whole buffer you've asked for.)

(You can inspect the source code at http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/cat.c ; safe_read (used instead of plain read) is in the gnulib submodule and it's a very simple wrapper around read(2) that abstracts away EINTR (see the man page)).

Best Answer

Related Solutions

What sets a child’s STDERR, STDOUT, and STDIN

Shell – How to forward between processes with named pipes

Related Question