From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25223 invoked by alias); 11 Apr 2011 14:45:21 -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: 15952 Received: (qmail 23772 invoked from network); 11 Apr 2011 14:45:10 -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.org does not designate permitted sender hosts) Date: Mon, 11 Apr 2011 16:39:30 +0200 From: Vincent Lefevre To: zsh-users@zsh.org Subject: Re: strange behavior Message-ID: <20110411143930.GA27818@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> <20110130003731.GL15921@prunille.vinc17.org> <110130142540.ZM15672@torch.brasslantern.com> <20110411142618.GA19503@ypig.lip.ens-lyon.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110411142618.GA19503@ypig.lip.ens-lyon.fr> X-Mailer-Info: http://www.vinc17.net/mutt/ User-Agent: Mutt/1.5.21-6171-vl-r42848 (2011-03-30) On 2011-04-11 16:26:18 +0200, Vincent Lefevre wrote: > On 2011-01-30 14:25:40 -0800, Bart Schaefer wrote: > > 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 reproduce the SIGPIPE problem when resizing the terminal window > while the wrapper is being run. According to strace, it's (3). and this is because the SIGWINCH seems to interrupt the "read" (is it a bug?), so that while read -r $timeout -k -u 0 ch do line="$line$ch" [[ $ch = $'\012' ]] && break timeout=(-t 0.1) done gives an empty string; hence the observed behavior. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)