Zsh Mailing List Archive
Messages sorted by:
Re: Tesing a fifo without opening it?
- X-seq: zsh-users 15386
- From: "Dominik Vogt" <dominik.vogt@xxxxxx>
- To: zsh-users@xxxxxxx
- Subject: Re: Tesing a fifo without opening it?
- Date: Fri, 10 Sep 2010 14:36:16 +0200
- In-reply-to: <20100910113632.GA4692@xxxxxxxx>
- List-help: <mailto:firstname.lastname@example.org>
- List-id: Zsh Users List <zsh-users.zsh.org>
- List-post: <mailto:email@example.com>
- Mailing-list: contact zsh-users-help@xxxxxxx; run by ezmlm
- References: <20100910063544.45240@xxxxxxx> <20100910113632.GA4692@xxxxxxxx>
> > 05 if read -t REQUEST < "$1"; then
> > Now, the problem is that input redirection in line 5 blocks
> > until the main script also opens the fifo. So the -t flag of
> > read does not "work" here (because read is not even executed
> > until the fifo can be opened). I want to check if data is
> > available in the fifo without blocking, but I can't find a way
> > around blocking in the input redirection.
> On Linux (at least, though the behavior is not clearly defined
> by POSIX)
> read -t REQUEST <> "$1"
> should work.
That prevents the shell from blocking, the reading shell does
not receive any data and the writing shell is killed by SIGPIPE:
1. Run "echo foo > fifo" in one shell W
2. W blocks when opening the fifo (no reader open)
3. Run "read -t 0 REQUEST <> fifo" in shell R
4. R opens the fifo without blocking.
5. W opens the fifo.
6. R runs "read -t 0" and notices that no data is available.
7. R closes the fifo.
8. W tries to write "foo" to the pipe.
9. As the pipe has already been closed, W gets SIGPIPE and dies.
So what is actually required is opening the shell non-blocking,
but blocking for input if the pipe could be opened.
I think I'm asking for something that is not possible without
precise control over the underlying syscalls.
> Otherwise, other approaches: open with O_NONBLOCK (though you'd
> need to do it in something else as I don't think zsh has an
> interface to open with O_NONBLOCK).
Right. I'm not aware that there is such an interface.
> Or you could do
> : > "$1" & read...
> though it would have other side effects.
Allright, this approach works:
$ : > fifo & read -t 1 REQUEST <> fifo; kill %
Thanks for helping!
Dominik ^_^ ^_^
P.S.: Please don't cc me; I'm on the list.
Achtung Sicherheitswarnung: GMX warnt vor Phishing-Attacken!
Messages sorted by: