This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author techtonik
Recipients loewis, sbt, techtonik, terry.reedy
Date 2013-09-29.19:03:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
On Sun, Sep 29, 2013 at 8:48 PM, Richard Oudkerk <> wrote:
>> Don't we have such function already? I don't see the problem in
>> quoting the string.
> No one seems to know how to write such a quoting function.

Why escape quotes with slash and surrounding in quotes doesn't help?
How does Linux and subprocess on Windows survive then?
If I am not mistaken both subprocess and execv on Windows use
CreateProcess. Does subprocess fail as well?

>> Does it start child process in foreground or in background? Did you
>> compile examples on
>> page with new
>> VC++ to check? I don't possess the VC++ 10, so I can't do this myself.
>> And I believe that compiling with GCC may lead to different results.
> There is no such thing as a background task in Windows.  A process is either attached to a console, or it isn't.  When you use execv() to start a process, it inherits the parent's console.

All right. Then why does it start to interfere with running cmd.exe
(in issue19124)? If it inherits console, it should continue to "own"
it exclusively, and not return it back to parent cmd.exe

> On Unix try replacing os.execv(...) by
>     os.spawnv(os.P_NOWAIT, ...)
>     os._exit(0)
> and you will probably get the same behaviour where the shell and the child process both behave as conflicting foreground tasks.

Maybe Python code doesn't use _execv() at all on Windows and uses
these spawnv's?

> ..
>> I don't mind if it runs child process with different pid, but why it
>> runs new process in background. Unix version doesn't do this.
> The point is that the shell waits for its child process to finish by using waitpid() (or something similar) on the child's pid.  If the child uses execv() then the child is replaced by a grandchild process with the same pid.  From the point of view of the shell, the child and the grandchild are the same process, and waitpid() will not stop until the grandchild terminates.

I can not accept your point when you don't know for sure how cmd.exe
waits for child process to exit. Are you sure that it doesn't use some
blocking CreateProcess call? Are you sure that Python on Windows calls
exactly _execv and not some spawn surrogate?

> This issue should be closed: just use subprocess instead.

We need some quorum on this. I'd like to hear two more people that can
confirm and agree with your position. I don't want to think that
usability of execv() on Windows can not be improved, because people
who love Linux doesn't think that this OS deserves some care. I'd like
to run Python scripts with the same base behaviour regardless of
platform. If that's impossible, that should be documented.
Date User Action Args
2013-09-29 19:03:26techtoniksetrecipients: + techtonik, loewis, terry.reedy, sbt
2013-09-29 19:03:26techtoniklinkissue19066 messages
2013-09-29 19:03:26techtonikcreate