From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <03e101c136b4$9abe9900$a2b9c6d4@SOMA> From: "Boyd Roberts" To: <9fans@cse.psu.edu> References: <633379943@snellwilcox.com> Subject: Re: Re[2]: [9fans] weird print(2) problems... MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Date: Thu, 6 Sep 2001 11:16:25 +0200 Topicbox-Message-UUID: ea62c49e-eac9-11e9-9e20-41e7f4b1d025 > Re: zero length messages on pipes > > I understood that read would return 0 for a zero length message, > and -1 on a read of a hungup (broken) pipe. on unix a broken pipe is when the reader goes away. the writer then gets sigpiped/epipe on the next write. the writer can exit before the reader, with no ill effects. err, if you were using a version of csh (all versions?) this could bite you badly 'cos a pipeline was incorrectly constructed; csh would wait on the first process and not the _last_. you have to fork the pipeline in reverse to get the right semantics, but csh did not do this. sh did. if your pipeline is: cmd | grep something > /dev/null it's the exit status of the grep that you want, not the exit status of cmd. 8th ed was modified to deal with dumb readers/writers by sigpipe, then sigkill after some number of bogus i/o's -- this was to trap programs that ignored error conditions. i guess this was initially added to limit the consumption of stream resources. dennis will correct me. it's early, i haven't even finished my first coke.