named pipe question

[Rajarshi Guha]

Hi,
I'm having a little trouble when I read from a named pipe. I create a
pipe by

os.mkfifo('/tmp/mypipe')

and then open it for reading with

fin = open('/tmp/mypipe','r+')

(I don't use 'r' as that cause the open command to block). However when I
do from another terminal:

ls -l /tmp/mypipe

and then from my Python session do:

fin.readlines()

it just hangs and I have to Ctrl-C to get out. But when I do from a
terminal:

ls -l /tmp/mypipe ; cat < /tm/mypipe

I get the output of the ls command. Why does'nt Python read from the pipe
when some other program writes to it?

Thanks,
Rajarshi

[Christopher T King]

On Tue, 13 Jul 2004, Rajarshi Guha wrote:

fin = open('/tmp/mypipe','r+')

(I don't use 'r' as that cause the open command to block).
It only blocks until a process connects to it for writing. 'r+' causes it
not to block because it causes 'fin' to be connected for both reading and
writing (probably not what you want). You should use 'r' as the mode.
ls -l /tmp/mypipe
You probably mean 'ls -l > /tmp/mypipe'. The command you have just lists
/tmp/mypipe; you need the redirection symbol to send the output to
/tmp/mypipe, otherwise it just ends up on the screen.
and then from my Python session do:

fin.readlines()

it just hangs and I have to Ctrl-C to get out.
This command will block until the writing process has closed the pipe.
Because you opened fin for both reading and writing, this command will
never return (it's basically waiting for itself to close).
But when I do from a terminal:

ls -l /tmp/mypipe ; cat < /tm/mypipe

I get the output of the ls command.

As above, this should be ls -l > /tmp/mypipe to work properly. This just
lists /tmp/mypipe directly to the screen. (It should probably block, too.)

Hope this helps.

[Donn Cave]

In article <pa************ *************** *@presidency.co m>,
Rajarshi Guha <ra******@presi dency.com> wrote:

I'm having a little trouble when I read from a named pipe. I create a
pipe by

os.mkfifo('/tmp/mypipe')

and then open it for reading with

fin = open('/tmp/mypipe','r+')

(I don't use 'r' as that cause the open command to block). However when I
do from another terminal:

ls -l /tmp/mypipe

and then from my Python session do:

fin.readlines()

it just hangs and I have to Ctrl-C to get out. But when I do from a
terminal:

ls -l /tmp/mypipe ; cat < /tm/mypipe

I get the output of the ls command. Why does'nt Python read from the pipe
when some other program writes to it?

Well, there may be a couple of issues here. The first is
that in order for anything to be read from a named pipe,
something has to be written to it. That's elementary, but
neither of your examples suggest that this is happening.

Once you're writing to it, you will find that readlines()
will work only when the writer closes its pipe file descriptor
(possibly by exiting), because readlines() can't return
until the entire "file" has been read.

Don't use a named pipe if an ordinary disk file would do.

Donn Cave, do**@u.washingt on.edu

[Tobiah]

> Don't use a named pipe if an ordinary disk file would do.

This may be a tad off topic, but in some ways it seems to
me that the converse is true. Discussion?

[John Lenton]

On Wed, 14 Jul 2004 17:57:42 -0700, Tobiah <to*********@rc sreg.com> wrote:

Don't use a named pipe if an ordinary disk file would do.

This may be a tad off topic, but in some ways it seems to
me that the converse is true. Discussion?

Files are both simpler and more powerful than named pipe: they don't
block, they don't necessarily have race conditions (on posix
filesystems), they can be locked, seeked, mmaped, compressed,
encrypted, ...

So, if a file does what you want, use a file. A named pipe is good for
the one thing it is good at: connecting _one_ reader and _one_ writer
in strict unidrectional synchrony when they aren't directly related in
the process tree, and when either one (or both) can't be modified to
use sockets instead. That's a niche for you.

--
John Lenton (jl*****@gmail. com) -- Random fortune:
bash: fortune: command not found