A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2005-June/054469.html below:

[Python-Dev] subprocess.call() and stdin

[Python-Dev] subprocess.call() and stdin [Python-Dev] subprocess.call() and stdinMichael Chermside mcherm at mcherm.com
Mon Jun 27 17:26:53 CEST 2005
Stuart Bishop writes:
> When I invoke subprocess.call(), I often want to ensure that the subprocess'
> stdin is closed. This ensures it will die if the subprocess attempts to read
> from stdin rather than block.
>
> This could be done if the subprocess.call() helper closes the input if
> stdin=subprocess.PIPE, which may be the only sane way to handle this
> argument (I can't think of any use cases for spawning a subprocess with an
> input stream that nothing can write too).

+0.5. I agree that if you pass "stdin=subprocess.PIPE" to subprocess.call()
that the current behavior of having the child process block forever is
totally useless. I have little reason to prefer "assume an empty input"
over "let subprocess.call() raise an exception if stdin==subprocess.PIPE"
-- but if I take your word for it that this is a common need, then that's
one good reason.

> It could also be done by adding a subprocess.CLOSED constant, which if
> passed to Popen causes a new closed file descriptor to be given to the
> subprocess.

-1.

It is easy enough to create a closed FD to read from... why complicate the
API?

-- Michael Chermside

More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4