From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15110 invoked by alias); 30 Jan 2011 22:25:53 -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: 15741 Received: (qmail 26941 invoked from network); 30 Jan 2011 22:25:50 -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,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <110130142540.ZM15672@torch.brasslantern.com> Date: Sun, 30 Jan 2011 14:25:40 -0800 In-reply-to: <20110130003731.GL15921@prunille.vinc17.org> Comments: In reply to Vincent Lefevre "Re: strange behavior" (Jan 30, 1:37am) 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> <20110130003731.GL15921@prunille.vinc17.org> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: strange behavior MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Jan 30, 1:37am, Vincent Lefevre wrote: } Subject: Re: strange behavior } } On 2011-01-28 07:49:15 -0800, Bart Schaefer wrote: } > 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. Possible epiphany: zsh prints "zsh: exit 141" like that only if the exit status came from a builtin or shell function (Src/exec.c). For all external commands or subshells it appends the jobtext after the status number (Src/jobs.c). Those are the only PRINTEXITVALUE cases. Thus the exit value of 141 must be coming from one of these places: (1) "read" builtin in the inner loop of "filter" (2) "printf" in the ?* branch of the case in "filter" (3) "echo" in the { ... } expression I can't imagine how "read" could return 141. For the { echo } statement, I get "zsh: broken pipe" every way I try to make it fail, before zsh ever gets around to PRINTEXITVALUE. That leaves "printf" ... Which at first let me to wonder if what's happening is that the inner while loop is failing to consume the entire svnwrapper:term$'\012' in a single pass around the outer loop, e.g. that the -t option you're adding after reading the first character causes read to time out on some calls instead of reading the next character. But that implies that the stderr of "filter" is getting closed somehow, and I can't think of a way that would happen. So I'm still stuck. What we need is an "strace -ff -o ..." or the equivalent to tell which process is printing that, but tracing may resolve the race condition and prevent the error. } 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. I don't understand what "wasn't redirected" means. Stderr is always redirected; "Broken pipe" could occur if svn prints something to stderr after 2>>(filter) has exited. I still can't figure out how to tie that to "zsh: exit 141" given the constraints above, though. } > 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? I meant that 2>>(...) is handled specially. Because "filter" is a shell function, it runs in a subshell which might have inherited the printexitvalue setopt from its parent. When filter exits inside the subshell, perhaps the subshell is printing "exit 141" before it also exits. *That* could correspond to printf barfing, but what would be closing the stderr of the command substitution?