From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25812 invoked from network); 7 Apr 2009 18:02:19 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 7 Apr 2009 18:02:19 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 76071 invoked from network); 7 Apr 2009 18:02:08 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 7 Apr 2009 18:02:08 -0000 Received: (qmail 28833 invoked by alias); 7 Apr 2009 18:01:58 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26824 Received: (qmail 28821 invoked from network); 7 Apr 2009 18:01:57 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 7 Apr 2009 18:01:57 -0000 Received: from cork.scru.org (cork.scru.org [209.20.67.2]) by bifrost.dotsrc.org (Postfix) with ESMTPS id 6B87D82D4B6A for ; Tue, 7 Apr 2009 20:01:50 +0200 (CEST) Received: by cork.scru.org (Postfix, from userid 1000) id 8F158104925; Tue, 7 Apr 2009 18:01:45 +0000 (UTC) Date: Tue, 7 Apr 2009 18:01:45 +0000 From: Clint Adams To: Peter Stephenson Cc: zsh-workers@sunsite.dk Subject: Re: tcp_read -d and newlines Message-ID: <20090407180145.GA13282@scru.org> Mail-Followup-To: Peter Stephenson , zsh-workers@sunsite.dk References: <20090405231036.GA13802@scru.org> <20090406095901.297232b0@news01> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090406095901.297232b0@news01> User-Agent: Mutt/1.5.18 (2008-05-17) X-Virus-Scanned: ClamAV 0.92.1/9211/Tue Apr 7 16:57:29 2009 on bifrost X-Virus-Status: Clean On Mon, Apr 06, 2009 at 09:59:01AM +0100, Peter Stephenson wrote: > I've had problems with this, too, in the past, although I think my problem > was chunks of input (not necessarily ending in EOF) that didn't have > newlines. I could find an easy way of handling this. It sounds like your > problem is when there is an EOF. Yes, I've had some mysteriously loss before but in this case I was definitely able to confirm that the transmission ended in not-a-newline. read processes the data, but returns an error so tcp_read tosses it. I don't actually need the input broken up into lines, so maybe I should be doing this differently.