Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: runaway zselect
- X-seq: zsh-users 14128
- From: Atom Smasher <atom@xxxxxxxxxxx>
- To: zsh-users@xxxxxxxxxx
- Subject: Re: runaway zselect
- Date: Mon, 18 May 2009 11:28:55 +1200 (NZST)
- In-reply-to: <090517144747.ZM959@xxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- Openpgp: id=0xB88D52E4D9F57808; algo=1 (RSA); size=4096; url=http://atom.smasher.org/pgp.txt
- References: <20090517044323.15333.qmail@xxxxxxxxxxx> <090517144747.ZM959@xxxxxxxxxxxxxxxxxxxxxx>
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
Messages sorted by:
Reverse Date,
Date,
Thread,
Author