From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3092 invoked by alias); 30 Jan 2011 00:43:27 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 15740 Received: (qmail 9881 invoked from network); 30 Jan 2011 00:43:23 -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: Sun, 30 Jan 2011 01:37:31 +0100 From: Vincent Lefevre To: zsh-users@zsh.org Subject: Re: strange behavior Message-ID: <20110130003731.GL15921@prunille.vinc17.org> Mail-Followup-To: zsh-users@zsh.org References: <20101102120943.GK19295@prunille.vinc17.org> <20101115163234.GE19451@prunille.vinc17.org> <101115092438.ZM29576@torch.brasslantern.com> <20101116031023.GF19451@prunille.vinc17.org> <20110128144412.GA22306@ypig.lip.ens-lyon.fr> <110128074915.ZM5855@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: <110128074915.ZM5855@torch.brasslantern.com> X-Mailer-Info: http://www.vinc17.net/mutt/ User-Agent: Mutt/1.5.21-6165-vl-r38670 (2010-12-30) On 2011-01-28 07:49:15 -0800, Bart Schaefer wrote: > I forget whether we covered this before, but does {svn "$@"} ever > fork as part of its execution? Yes (for SSH connection, and the ssh script can start a SSH master connection, which will still run in background after svn terminates, and that's why I needed the svnwrapper:term trick in my script). > There has to be some kind of race condition here. 2>>(filter) runs > filter in the background, so if something behind svn also runs as an > separate process, it could be possible for the filter to exit and > close it's stdin (thereby closing everything else's stdder) before > operating-system-level exit-time buffer-flushing has finished. Yes, this happens, but I don't see why this could make the script terminate with a broken pipe. I recall the whole script: filter() { unset brpipe while true do unset line timeout while read -r $timeout -k -u 0 ch do line="$line$ch" [[ $ch = $'\012' ]] && break timeout=(-t 0.1) done case $line in svnwrapper:term$'\012') break ;; *Broken\ pipe$'\012') brpipe=1 ;; ?*) printf "%s" "$line" >&2 ;; *) break ;; # empty line (end of file) - parent has died? esac done # The "sleep 5" is there to avoid a rare race condition (it occurred # once): make sure the parent process receives the PIPE signal before # the filter process terminates (which can yield a SIGPIPE in svn). [[ -z $brpipe ]] || { kill -PIPE $$; sleep 5 } } { svn "$@"; st=$?; echo "svnwrapper:term" >&2 } 2>>(filter) exit $st Because of the "while true" loop, filter should still run after svn terminates. Note that when I obtained the "zsh: exit 141", the svn output wasn't redirected, so that a "Broken pipe" message from svn was not possible. > Hmm, another thought ... maybe the "zsh: exit 141" is coming from > the shell's exit-time handling of the "filter" program, rather than > from svn. I've lost enough context here that I don't recall whether > that was previously ruled out too. What do you mean here? -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)