The following code snippet should die instead of hang.

>>> from subprocess import call, PIPE
>>> rv = call(['/usr/bin/bzip2', '-c'], stdout=PIPE,
stdin=PIPE)

It makes no sense not to close stdin if it is PIPE
because the stream cannot be accessed.

The use case for this is ensuring a subprocess that
detects if it is connected to a terminal or not runs in
'batch' mode, and that it will die instead of hang if
it unexpectidly attempts to read from stdin.

Workaround is to use Popen instead.

Logged In: YES 
user_id=344921

>It makes no sense not to close stdin if it is PIPE
>because the stream cannot be accessed

True, but what if you actually *want* to create an
inaccessible pipe, and give it to the child?

Currently, the call() wrapper is *very* short and simple. I
think this is very good. For example, it allows us to
document it in two sentences. You get what you ask for: If
you use call() with strange arguments, you'll get a somewhat
strange behavíour. I see no point in introducing lots of
sanity checks in the wrapper functions. 

>The use case for this is ensuring a subprocess that
>detects if it is connected to a terminal or not runs in
>batch' mode, and that it will die instead of hang if
>it unexpectidly attempts to read from stdin

I'm not sure I understand what you want, but if you want to
have stdin connected to a closed file descriptor, just pass one:

>>> from subprocess import call, PIPE
>>> rv = call(['/usr/bin/bzip2', '-c'], stdout=PIPE,
stdin=4711)

(Of course, you should verify that 4711 is unused.)

If you don't agree with me, post to python-dev for discussion. 

Logged In: YES 
user_id=46639

I can't think of any uses cases for wanting to create an
inaccessible pipe and give it to the child. 

Wanting to pass a closed file handle is common. It is needed
when calling a program that behaves differently if its stdin
is a terminal or not. Or when you simply would prefer the
subprocess to die if it attempts to read from its stdin
rather than block.

Using Popen instead of call is s simpler workaround than
creating and closing a file descriptor and passing it in.

Perhaps what is needed is a new constant, subprocess.CLOSED
which creates a new file descriptor and closes it? This
would be useful for Popen too, allowing call() to remain a
think and trivially documented wrapper?

Logged In: YES 
user_id=344921

>Wanting to pass a closed file handle is common. 

This is not my experience. 

>It is needed when calling a program that behaves
differently if its stdin
>is a terminal or not. 

Such programs are quite uncommon, and usually, it's a bad
idea to make such checks anyway. 

>Or when you simply would prefer the subprocess to die if it
attempts to >read from its stdin rather than block

For this case, I would say that it's more common to pass
/dev/null than a closed file descriptor. It's uncommon with
shell scripts that does "someprogram <&4711". It's much more
common with "someprogram </dev/null". With subprocess, this
is already easy:

...stdin=open("/dev/null"). 

>Using Popen instead of call is s simpler workaround than
>creating and closing a file descriptor and passing it in.

How would you use Popen in this case?

>Perhaps what is needed is a new constant, subprocess.CLOSED
>which creates a new file descriptor and closes it? This
>would be useful for Popen too, allowing call() to remain a
>think and trivially documented wrapper?

It's not very hard to get an unused FD:

closed_fd = os.open("/dev/null", os.O_RDONLY);
os.close(closed_fd)

I'm a bit reluctant to add a new constant when you can solve
the problem anyway with one line of code. 

Also, we'll need to think about the platform portability a
bit. Currently, I think that if we should add anything at
all, it should be a constant like subprocess.NULL, which
would be basically like open("/dev/null"), but also 
portable to Windows.