Re: process substitution and Ctrl-C

[Vincent Lefevre <vincent@vinc17.net>]

On 2010-08-19 08:32:37 -0700, Bart Schaefer wrote:
> On Aug 19,  2:41pm, Vincent Lefevre wrote:
> } 
> } In the following example:
> } 
> }   { repeat 10 { date >&2; /bin/sleep 1 } } 2>>(cat -n; loop)
> } 
> } where "loop" is a program that consumes CPU time, is it normal that
> } when one interrupts the command with Ctrl-C, the substituted process
> } isn't killed? (I can see "loop" taking CPU time.)
> 
> The assumption is that process substitution consumes stdin and exits
> after its stdin is closed.  Otherwise, why would you need to redirect
> into it?

However there's a race condition, IMHO. In fact, even without a signal
to the main process. For instance, if you consider:

  ls >>(cat -n)

then the zsh prompt for the next command is displayed before "cat -n"
finishes. Does this mean that process substitution should not be used
for filtering, except when an end marker is used (as in the example
at the end of my message)? Now,

  { ls } >>(cat -n)

seems to work (as you said), and this can be seen with:

  { ls } >>(sleep 2; cat -n)

but no longer if the main process is interrupted with Ctrl-C.
For instance:

  { ls } >>(while read line; do sleep 1; echo $line; done)

outputs one line each second, and the main process is blocked as
wanted; but if one does a Ctrl-C, the main process is terminated
and one gets the prompt while the substituted process still outputs
the remaining lines each second. I don't think this is the behavior
that one expects.

In fact, I noticed the problem with the Ctrl-C due to a bug in one
of my scripts:

filter()
{
  unset brpipe
  while true
  do
    unset line
    while read -r -t 0.1 -k -u 0 ch
    do
      line="$line$ch"
      [[ $ch = $'\012' ]] && break
    done
    case $line in
      svnwrapper:term$'\012')
        break ;;
      *Broken\ pipe$'\012') brpipe=1 ;;
      ?*) printf "%s" "$line" >&2 ;;
    esac
  done
  [[ -z $brpipe ]] || kill -PIPE $$
}

{ svn "$@"; st=$?; echo "svnwrapper:term" >&2 } 2>>(filter)
exit $st

The problem here is that I didn't do the difference between a timeout
(due to -t 0.1) and an end of file: in the case of a Ctrl-C while svn
was running, the end marker svnwrapper:term would no longer be output
and filter() would start to take CPU time in an infinite loop. I've
fixed the script by using -t 0.1 as of the second iteration only:

[...]
    unset line timeout
    while read -r $timeout -k -u 0 ch
    do
      line="$line$ch"
      [[ $ch = $'\012' ]] && break
      timeout=(-t 0.1)
    done
[...]

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)