Re: runaway zselect

[Atom Smasher <atom@smasher.org>]

cool... thanks!


On Sun, 17 May 2009, Bart Schaefer wrote:

> On May 17,  4:43pm, Atom Smasher wrote:
> }
> } i would expect zselect to return an error and stop the while loop when
> } "w" stops producing output.
>
> That's not how the select() system call works.  The descriptor is still 
> open on the reading end of the pipe even though the descriptor on the 
> writing end of the pipe has been closed.  That means from select()'s 
> point of view, the descriptor is available for reading, even though the 
> only thing that can be read from it is the end-of-file condition.
>
> If this were not the case, zselect would fail as soon as the writer 
> exits, even if all output from the writer had not yet been consumed. 
> (Remember that there is OS-level buffering involved, so the writing end 
> may be closed before the pipe is "empty".)
>
> What you need to fix this is to test the result of "read" as well. 
> Either:
>
>    while zselect -r 0 && read -r foo
>    do
> 	print -r -- $foo
>    done <<( w )
>
> Or equivalently:
>
>    while zselect -r 0
>    do
> 	read -r foo || break
> 	print -r -- $foo
>    done <<( w )
>
>


-- 
         ...atom

  ________________________
  http://atom.smasher.org/
  762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
  -------------------------------------------------

 	"I am committed to helping Ohio deliver its electoral
 	 votes to the president [Bush] next year"
 		-- Walden O'Dell, CEO of Diebold
 		August 2003