Python 2.2.1: os.popen() bug?
Carsten Gaebler
If I write to a pipe that was opened read-only, python throws an
exception, but then the interpreter hangs instead of exiting. Is this
beavior expected or a bug? Consider this example on Linux:
#! /usr/bin/python
import os
pipe = os.popen("mail -s Test f...@bar.org")
print >> pipe, "Test" # Raises IOError.
pipe.close() # Never reached.
Regards,
Carsten.
Denis S. Otkidach
CG>
CG> If I write to a pipe that was opened read-only, python
CG> throws an
CG> exception, but then the interpreter hangs instead of
CG> exiting. Is this
CG> beavior expected or a bug? Consider this example on Linux:
CG>
CG> #! /usr/bin/python
CG>
CG> import os
CG>
CG> pipe = os.popen("mail -s Test f...@bar.org")
You have opened pipe for reading, try:
pipe = os.popen("mail -s Test f...@bar.org", "w")
CG> print >> pipe, "Test" # Raises IOError.
CG> pipe.close() # Never reached.
Dmitri I GOULIAEV
On Mon, May 27, 2002 at 03:48:33PM +0400, Denis S. Otkidach wrote:
> On Mon, 27 May 2002, Carsten Gaebler wrote:
>
> CG> If I write to a pipe that was opened read-only, python throws an
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> CG> exception, but then the interpreter hangs instead of exiting. Is this
> CG> beavior expected or a bug? Consider this example on Linux:
> CG>
> CG> #! /usr/bin/python
> CG>
> CG> import os
> CG>
> CG> pipe = os.popen("mail -s Test f...@bar.org")
>
> You have opened pipe for reading, try:
Exactly. He told he will open a pipe read-only.
His question was about interpreter' reaction in this situation.
--
DIG (Dmitri I GOULIAEV)
All below this line is added by my e-mail provider.
Donn Cave
I think you'll find that the same happens even if you don't write
to it.
On exit, Python cleans up everything, and its cleanup for your "pipe"
file object eventually calls pclose(3). That function closes the
pipe, and then waits for the process to exit so it can return the
exit status. That works -- if the process on the other end is
actually going to use the pipe. If you had supplied the 'w' option,
mail would have seen EOF at that point, and would have gone on to
send the mail and exit. If it had been for some reason writing to
output, it would have gotten a SIGPIPE. But it doesn't write to
output, it just sits there and waits for input. And Python's cleanup
procedure waits for it.
Donn Cave, do...@u.washington.edu
Michael Hudson
> If it had been for some reason writing to output, it would have
> gotten a SIGPIPE.
Not sure about context, but Python ignores SIGPIPEs by default. So
this is probably not much use.
Cheers,
M.
--
surely, somewhere, somehow, in the history of computing, at least
one manual has been written that you could at least remotely
attempt to consider possibly glancing at. -- Adam Rixey
Donn Cave
| "Donn Cave" <do...@u.washington.edu> writes:
|
| > If it had been for some reason writing to output, it would have
| > gotten a SIGPIPE.
|
| Not sure about context, but Python ignores SIGPIPEs by default. So
| this is probably not much use.
Oops, thanks for catching that. I see a command process forked
from python by popen() does inherit that behavior.
So I guess it's just a bad idea to use popen(cmd, 'r') unless cmd
can be relied on to terminate on its own. Unlike C popen(), the
cmd process from a Python popen() will continue to write to its
output unit forever, and python will wait forever, until someone
aborts it externally. It won't be a common problem, only applies
to applications that talk forever, like "ping" or "tail -f".
In a case like that, one would want to defeat this questionable
feature prior to popen(), e.g.,
signal.signal(signal.SIGPIPE, signal.SIG_DFL)
Donn Cave, do...@u.washington.edu