>>>> He tested /dev/stdin that didn't work either, and a socket that
>>> That really depends on what type of file stdin was attached to,
>>> and whether that file type supported read filters (or not).
>>> Without knowing that, I can't tell you if it should have worked
>>> or not. Obviously, it should always work on sockets, whose data
>>> is known to arrive asynchronously, and therefore read filters are
>>> As a general comment, if you hit an EOF, expect the filter to
>>> become disabled.
>> I found it doesn't seem to work if stdin is attached to the
>> standard input.
>> Maybe EV_POLL would be some help in that case?
> I'm still not parsing this - I know it's stdin, I just don't know
> what it's connected to.
> Specifically, /dev/stdin is an alias for /dev/fd/0, which is an
> alias for "whatever is open on this processes fd 0".
> Doing a stat on the fd should be informative as to what the heck
> the descriptor is hooked up to.
This is what I gather from fstat:
device=219b1d4 inode=21bc504 uid=503 gid=4 devicetype=4000005
I don't know how to interpret this device type, but it is really the
standard (console) input. I don't know how to define this better.
> If it's a regular file, then yes, EV_POLL might be some help.
I couldn't see a difference with or without EV_POLL in the filter-
I asked the customer for sample code. Can I send it to you after
weeding it out?
> If it's something like a socket or something else, then he'd be
> better off if he'd just use fd 0, rather than /dev/fd/0 or /dev/
> stdin, since at present it's not possible to reopen sockets via /
> dev/fd0 or /dev/stdin (he's checking the open to see if it fails,
> Like I said before, it really depends on the type of file stdin is
> attached to.
> -- Terry