From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Mon, 20 Nov 2006 13:49:23 -0500 From: "Russ Cox" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] echo -n In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Topicbox-Message-UUID: e28c8e96-ead1-11e9-9d60-3106f5b1d025 > Why is read from a closed pipe not considered an error, though? The same reason that reading from the end of a disk file is not an error. Try running your program reading /dev/null instead of a pipe. > close(fd[0]); > for(int i=0; i<5; i++){ > n = read(fd[1], buf, 8); > print("%d: read %ld bytes: %r\n", i, n); > } > produces: > 0: read 0 bytes: > 1: read 0 bytes: > 2: read 0 bytes: > 3: read -1 bytes: i/o on hungup channel > 4: read -1 bytes: i/o on hungup channel > where I expected errstr to be set on the first read after pipe > closure. Errstr is only set when a system call returns -1. > Is there really no way to immediately determine that a > pipe has been closed? Why would read be so implemented? It's a clumsy hack to work around exactly this problem. It's not read in general that is implemented this way, just the read implementation for pipes and network data files. The only real solution is to change the interface so that end-of-file is not signaled by a zero-length read. But that convention is far too entrenched to go anywhere any time soon. Russ