From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] weird print(2) problems... From: forsyth@vitanuova.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-djqlrmcaulxumpldnkxdkefnqq" Message-Id: <20010905150808.1FC2619A32@mail.cse.psu.edu> Date: Wed, 5 Sep 2001 16:11:58 +0100 Topicbox-Message-UUID: e9ff5e54-eac9-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-djqlrmcaulxumpldnkxdkefnqq Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit >>that if write(2) sees a zero length argument, it should consider that a >>nop and return. But then it seems that that would break some weird >>semantic somewhere (``Any write will update a timestamp; except for >>zero length writes, which are ignored.'' ``Dude, that's broken.'') it isn't only the possible effect on time stamps; i think it should do a write 0 because it's what you said to do. to be fair, it's disguised by print, but even so, if i wanted nop() i'd use ; or void nop(void){} but i wouldn't call write() or even print. i'd call write() when i wanted to write, and i prefer systems that do what i tell it, so that if i say `write 0 bytes' i expect it to do that, rather than adding yet more special cases to remember. the effect of writing 0 bytes is determined by the device, but that's true of writing 1 byte or many, so there's no difference there. on the other hand, i'd probably write if(*str) print("%s", str); if that's what i wanted. --upas-djqlrmcaulxumpldnkxdkefnqq Content-Type: message/rfc822 Content-Disposition: inline Return-Path: <9fans-admin@cse.psu.edu> Received: from punt-2.mail.demon.net by mailstore for forsyth@vitanuova.com id 999699855:20:06567:24; Wed, 05 Sep 2001 14:24:15 GMT Received: from psuvax1.cse.psu.edu ([130.203.4.6]) by punt-2.mail.demon.net id aa2114624; 5 Sep 2001 14:23 GMT Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.18.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 98D2319A04; Wed, 5 Sep 2001 10:23:05 -0400 (EDT) Received: from math.psu.edu (leibniz.math.psu.edu [146.186.130.2]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 12B69199EF for <9fans@cse.psu.edu>; Wed, 5 Sep 2001 10:22:19 -0400 (EDT) Received: from augusta.math.psu.edu (augusta.math.psu.edu [146.186.132.2]) by math.psu.edu (8.9.3/8.9.3) with ESMTP id KAA07789 for <9fans@cse.psu.edu>; Wed, 5 Sep 2001 10:22:18 -0400 (EDT) Received: (from cross@localhost) by augusta.math.psu.edu (8.9.3+Sun/8.9.3) id KAA02761; Wed, 5 Sep 2001 10:22:18 -0400 (EDT) Message-Id: <200109051422.KAA02761@augusta.math.psu.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] weird print(2) problems... Newsgroups: comp.os.plan9 In-Reply-To: <20010904190825.3180.qmail@f.bio.cse.psu.edu> References: Organization: Mememememememmeme Cc: Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.6 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Wed, 5 Sep 2001 10:22:18 -0400 (EDT) In article <20010904190825.3180.qmail@f.bio.cse.psu.edu> you write: >Hm. Pipes in Plan 9 preserve write boundaries, right? Print is probably >sending a zero length write, and confusing programs that interpret it >as eof. Hmm, that seems plausible. It's also rather annoying; it seems to me that if write(2) sees a zero length argument, it should consider that a nop and return. But then it seems that that would break some weird semantic somewhere (``Any write will update a timestamp; except for zero length writes, which are ignored.'' ``Dude, that's broken.'') Is there an elegant solution (other than ``don't do print("");'', since that might really mean ``don't do, read(0, str, 128); trimwhitespace(str); print("%s", str); where the only thing read is a blank line or something.'')? - Dan C. --upas-djqlrmcaulxumpldnkxdkefnqq--