Popen3 and capturestderr

Kenneth Pronovici pronovic at skyjammer.com
Wed Mar 9 19:06:29 CET 2005


On Wed, Mar 09, 2005 at 06:17:50AM -0000, Donn Cave wrote:
> Quoth Kenneth Pronovici <pronovic at skyjammer.com>:
> ...
> | If ignoreStderr=False, I use popen2.Popen4 so that stderr and stdout are
> | intermingled.  If ignoreStderr=True, I use popen2.Popen3 with
> | capturestderr=True so stderr doesn't appear in the output.  This
> | functionality exists so I have an equivalent of command-line redirection
> | of stderr, i.e. command 2>/dev/null.  
> ...
> | After some digging, I've decided that this behavior probably occurs
> | because I am ignoring the pipe.childerr file object.  Indeed, if I call
> | pipe.childerr.close() right after opening the pipe, my "ls" command that
> | had been hanging completes normally.  However, other commands which
> | actually attempt to write to stderr don't seem to like this very much.
> |
> | What is the right way to discard stderr when working with a pipe?  I
> | want to consistently throw it away, and I don't see a good way to do
> | this with the popen2 implementation.
> 
> Right, popen2 gives you about 3 options, out of probably dozens that
> you could get with shell redirections.  On the other hand, the source
> is available, and Python is an OOP language, so I assume there is no
> reason you can't make a derived class that does just what you want.
> In the present case I guess that would mean something like
>    null = os.open('/dev/null', os.O_RDWR)
>    os.dup2(null, 0)
>    os.dup2(null, 2) (depending)
>    os.close(null)
> along with other stuff you can just copy from Popen4.

Ah... ok, subclassing is an option I hadn't considered.  I'll give that
a whirl and see whether I can make it work.

KEN

-- 
Kenneth J. Pronovici <pronovic at ieee.org>
Personal Homepage: http://www.skyjammer.com/~pronovic/
"They that can give up essential liberty to obtain a little 
 temporary safety deserve neither liberty nor safety." 
      - Benjamin Franklin, Historical Review of Pennsylvania, 1759 



More information about the Python-list mailing list