From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-users-return-15302-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 26144 invoked by alias); 19 Aug 2010 21:17:27 -0000
Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Users List <zsh-users.zsh.org>
List-Post: <mailto:zsh-users@zsh.org>
List-Help: <mailto:zsh-users-help@zsh.org>
X-Seq: 15302
Received: (qmail 25294 invoked from network); 19 Aug 2010 21:17:24 -0000
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	version=3.3.1
Received-SPF: none (ns1.primenet.com.au: domain at vinc17.net does not designate permitted sender hosts)
Date: Thu, 19 Aug 2010 23:17:21 +0200
From: Vincent Lefevre <vincent@vinc17.net>
To: zsh-users@zsh.org
Subject: Re: process substitution and Ctrl-C
Message-ID: <20100819211721.GB16241@prunille.vinc17.org>
Mail-Followup-To: zsh-users@zsh.org
References: <20100819124142.GQ16075@prunille.vinc17.org>
 <100819083237.ZM26692@torch.brasslantern.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <100819083237.ZM26692@torch.brasslantern.com>
X-Mailer-Info: http://www.vinc17.org/mutt/
User-Agent: Mutt/1.5.20-6127-vl-r38670 (2010-08-14)

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)