From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16283 invoked from network); 13 Feb 2004 21:24:57 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 13 Feb 2004 21:24:57 -0000 Received: (qmail 22447 invoked by alias); 13 Feb 2004 21:22:09 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7052 Received: (qmail 22432 invoked from network); 13 Feb 2004 21:22:09 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 13 Feb 2004 21:22:09 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [68.1.17.113] by sunsite.dk (MessageWall 1.0.8) with SMTP; 13 Feb 2004 21:22:8 -0000 Received: from quark.hightek.org ([68.12.75.33]) by lakemtao08.cox.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040213212208.VBKT2412.lakemtao08.cox.net@quark.hightek.org> for ; Fri, 13 Feb 2004 16:22:08 -0500 Received: by quark.local (Postfix, from userid 501) id CC60E11E23; Fri, 13 Feb 2004 11:33:48 -0600 (CST) Date: Fri, 13 Feb 2004 11:33:48 -0600 From: Vincent To: zsh-users@sunsite.dk Subject: Re: |& loses data (buffering bug?) Message-ID: <20040213173348.GA30557@quark.local> References: <20040213141505.GG27168@greux.loria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040213141505.GG27168@greux.loria.fr> User-Agent: Mutt/1.4.1i On Fri, Feb 13, 2004 at 03:15:05PM +0100, Vincent Lefevre wrote: > Contents from stdout have been lost here. The problem occurs either > with less or with grep; for instance, a "cvs status |& grep Status" > gave: > > [...] > File: replace_all Status: Up-to-date > File: rint.c Status: Up-to-date > File: round_prec.c Status: Up-t > File: set_str.c Status: Up-to-date > File: set_str_raw.c Status: Up-to-date > [...] > > instead of: > > [...] > File: replace_all Status: Up-to-date > File: rint.c Status: Up-to-date > File: round_prec.c Status: Up-to-date > File: round_raw_generic.c Status: Up-to-date > File: save_expo.c Status: Up-to-date > File: set.c Status: Up-to-date > File: set_d.c Status: Up-to-date > File: set_dfl_prec.c Status: Up-to-date > File: set_exp.c Status: Up-to-date > File: set_f.c Status: Up-to-date > File: set_inf.c Status: Up-to-date > File: set_ld.c Status: Up-to-date > File: set_nan.c Status: Up-to-date > File: set_prc_raw.c Status: Up-to-date > File: set_prec.c Status: Up-to-date > File: set_q.c Status: Up-to-date > File: set_rnd.c Status: Up-to-date > File: set_si.c Status: Up-to-date > File: set_str.c Status: Up-to-date > File: set_str_raw.c Status: Up-to-date > [...] > > When I redirect the output of the second command to a file, it seems > that the problem never occurs. > > Is it a bug from zsh (I'm using zsh 4.0.9) or from cvs? That is weird. It looks to me like you might be encountering YALKB (Yet Another Linux Kernel Bug) :-). I just tested the "cvs status |& grep Status" command on FreeBSD with zsh-4.1.1 and get no data loss. You might want to try a different version kernel and see if it still does it. Another way to confirm one way or the other, if you have a machine to test on, is to install FreeBSD and run the same linux binaries of zsh and cvs on it with the linux_base package installed (for running Linux binaries) and see if the problem still exists. We discovered that many of the bugs and instabilities we had wrongly blamed for a long time on applications such as our in-house CAD system did not exist on FreeBSD, even running the same binaries, without re-compiling native to FreeBSD. We left Linux well over a year ago after almost 10 years of usage because of all the crashes and weird memory management bugs and all of the weird problems went away.