coproc not flushing all output?

[clemens fischer]

I have a script going through ELF files and finding which of them refer
to non-existing shared libraries.  After finding the files, it proceeds
by checking which package they belong to, which is an expensive
operation, so it is done in a "coproc" co-process.

The main loop knows when all the files have been sent to the "checker"
co-process and sends a special filename as an "exit" command.  In the
original design, "checker" would immediately exit upon seeing this
special command.  On unix-like systems, "exit" means "flush all output
and terminate afterwards", but on bash-4.0.24(1)-release a co-process
seems to exit somewhere in between.

I need to resort to the following workaround:

 coproc checker {
     checker_fail_cnt=0
     while true
     do
         [ ${checker_fail_cnt} -gt 0 ] && {
             let ++checker_fail_cnt
             echo_v 3 "checker: checker_fail_cnt: ${checker_fail_cnt}"
             [ ${checker_fail_cnt} -gt ${checker_fail_cnt_max} ] && break
             sleep 1
             continue
         }
         read dafile
         case "_${dafile}" in
             "_${checker_exit}")
                 echo_v 3 "checker: shutting down on '${checker_exit}'"
                 echo "${checker_exit}"
                 let ++checker_fail_cnt
                 continue
                 ;;
         esac
         # do stuff with any file names sent on stdin ...
     done
     exit 0
 }

It delays exiting for ${checker_fail_cnt_max}+1 seconds, while the main
process hurries to read out everything "checker" has already sent.

If I simply do this:

 coproc checker {
     while true
     do
         read dafile
         case "_${dafile}" in
             "_${checker_exit}")
                 echo_v 3 "checker: shutting down on '${checker_exit}'"
                 echo "${checker_exit}"
                 break
                 ;;
         esac
         # do stuff with any file names sent on stdin ...
     done
     exit 0
 }

and let the main process read until it sees "${checker_exit}" coming
back, it will almost never receive it.  Instead, its "read -u
${checker[0]}" will return an exit code of one eventually without having
read all that "checker" ever sent.

Since my workaround will leave a useless process sitting for a while or
until killed explicitly, I'd like to get rid of it.  Using a timeout in
the main process is equally unacceptable:  it slows down the final steps
and it doesn't guarantee receiving a complete output line.  Also, this
application is quite simple:  there must be an output from "checker" for
every input to it.  In the future I may have much looser coupling
between processes.

Is there a better workaround until this is fixed?


regards, clemens