after calling os.popen('yes | echo hello'), the process never returns.

Could you try the same command from your shell?

I am guessing "yes" will write an error message about the broken pipe to stderr.

$ python -c 'import sys, os; sys.stdout.write(os.popen("yes | echo hello").read())'
yes: standard output: Broken pipe
yes: write error
hello

$ python -c 'import sys, os; sys.stdout.write(os.popen3("yes | echo hello")[1].read())'
hello

command line also get stuck.  The OS is MacOSX.  Python version 2.3.5.  Will it help update to new version?

I quited the program by Ctrl-C.

 python -c 'import sys, os; sys.stdout.write(os.popen("yes | echo hello").read())'
^CTraceback (most recent call last):
  File "<string>", line 1, in ?
KeyboardInterrupt



% python -c 'import sys, os; sys.stdout.write(os.popen3("yes | echo hello")[1].read())'
^CTraceback (most recent call last):
  File "<string>", line 1, in ?
KeyboardInterrupt

I've realized my suggestion was not precise.  I meant asking to run the argument to popen() rather than popen().

That is, I would run this from command line to see if there is an issue with the shell:

$ yes | echo hello

sorry for the misunderstanding.

Here is the result. 

% yes | echo hello
hello
% echo $?
0
%

It appears your "yes" does not catch SIGPIPE.  I've reproduced the issue with

$ python -c 'import sys, os; sys.stdout.write(os.popen("while :; do echo yes ; done | echo hello").read())'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
KeyboardInterrupt

The documentation on Python module signal says SIGPIPE is ignored by Python as well.  My work-around to this was to catch SIGPIPE, but the GNU C library would terminate the whole script.

$ python -c 'import sys, os, signal; signal.signal(signal.SIGPIPE, signal.SIG_DFL); sys.stdout.write(os.popen("while :; do echo yes ; done | echo hello").read())'
hello

http://www.gnu.org/software/libc/manual/html_node/Operation-Error-Signals.html

Perhaps, writing own signal handler might help.

The SIG_DFL default handler seems to terminate the current process (argument to popen()), not Python script.

It works now. thank you.

I don't think this is a bug in python (see below for analysis). Furthermore, os.popen() is deprecated, so I think this issue can be closed.


Here is my understanding of what's happening.

When you execute :

 python -c 'import sys, os; sys.stdout.write(os.popen("while :; do echo  yes ; done | echo hello").read())'

popen() forks and then execs() a /bin/sh like this

 /bin/sh -c "while :; do echo  yes ; done | echo hello"

But exec() (on Linux at least) inherits the signal handling from the pre-exec process for the signals which were set to SIG_IGN or SIG_DFL (see e.g here: http://www.gnu.org/software/libc/manual/html_node/Initial-Signal-Actions.html), so in this case shell will inherit SIG_IGN setting from python for SIGPIPE.

Furthermore, the "sh" manpage explicitly says that shell will wait for all processes in the pipeline. 

So, the sequence of events will be as follows: echo exits, SIGPIPE is delivered to the shell and is ignored by the shell and so the shell keeps running the while loop forever, so .read() call never reaches the eof and your script blocks.

The original "yes|echo" example on MacOsX has likely been caused by the same sequence of events. (if "yes" inherits signal handling from shell, then "yes|echo"
would not block when invoked from command line, but would block when invoked from python)

Installling your own SIGPIPE handler (or resetting SIGPIPE to SIG_DFL as ilgiz suggested) should work around this issue.

See also issue 1652, noting as well that os.popen is implemented via subprocess in py3k.

issue 1652 will take care of this problem.  i'm working on it.