[issue19066] os.execv fails with spaced names on Windows
Changes by Terry J. Reedy tjre...@udel.edu: -- resolution: - duplicate status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19066 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19066] os.execv fails with spaced names on Windows
anatoly techtonik added the comment: I tested with 2.7 and 3.3, but this is true for any version. If the bug is actual for Python 2.6, 3.1 and 3.2 why should I uncheck them? Versions field description doesn't say that I should mark only latest change. In addition, people (unlikely, but still) may search for specific versions to see which bugs were reported against them and fixed in later releases. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19066 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19066] os.execv fails with spaced names on Windows
Terry J. Reedy added the comment: The versions are the versions that will be patched for the issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19066 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19066] os.execv fails with spaced names on Windows
anatoly techtonik added the comment: It should be documented somehow then. At least in the field tooltip. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19066 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19066] os.execv fails with spaced names on Windows
Richard Oudkerk added the comment: See http://bugs.python.org/issue436259 This is a problem with Window's implementation of spawn*() and exec*(). Just use subprocess instead which gets this stuff right. Note that on Windows exec*() is useless: it just starts a subprocess and exits the current process. You can use subprocess to get the same effect. -- nosy: +sbt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19066 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19066] os.execv fails with spaced names on Windows
anatoly techtonik added the comment: On Sun, Sep 29, 2013 at 2:05 PM, Richard Oudkerk rep...@bugs.python.org wrote: See http://bugs.python.org/issue436259 I am not sure that I should see there. There is discussion of DOS, which is not supported, also some complain about Windows execv function, which deprecated since VC++ 2005 (which I hope also not supported). Can you be more specific? This is a problem with Window's implementation of spawn*() and exec*(). Note that on Windows exec*() is useless: it just starts a subprocess and exits the current process. You can use subprocess to get the same effect. Are you describing Windows implementation of _exec() http://msdn.microsoft.com/en-us/library/431x4c1w.aspx or current Python implementation? Just use subprocess instead which gets this stuff right. subprocess doesn't replace os.exec*, see issue19060 -- title: os.execv fails with spaced names on Windows - os.execv fails with spaced names on Windows ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19066 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19066] os.execv fails with spaced names on Windows
Richard Oudkerk added the comment: I am not sure that I should see there. There is discussion of DOS, which is not supported, also some complain about Windows execv function, which deprecated since VC++ 2005 (which I hope also not supported). Can you be more specific? _spawn*() and _exec*() are implemented by the C runtime library. spawn*() and execv() are (deprecated) aliases. The the first message is about someone's attempt to work around the problems with embedded spaces and double quotes by writing a function to escape each argument. He says he had a partial success. Surely this is basic reading comprehension? Note that on Windows exec*() is useless: it just starts a subprocess and exits the current process. You can use subprocess to get the same effect. Are you describing Windows implementation of _exec() http://msdn.microsoft.com/en-us/library/431x4c1w.aspx or current Python implementation? The Windows implementaion of _exec(). Just use subprocess instead which gets this stuff right. subprocess doesn't replace os.exec*, see issue19060 On Unix subprocess does not replace os.exec*(). That is because on Unix exec*() replaces the current process with a new process with the *same pid*. subprocess cannot do this. But on Windows os.exec*() just starts an independent process with a *different pid* and exits the current process. The line os.execv(path, args) is equivalent to os.spawnv(os.P_NOWAIT, path, args) os._exit(0) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19066 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19066] os.execv fails with spaced names on Windows
anatoly techtonik added the comment: On Sun, Sep 29, 2013 at 3:03 PM, Richard Oudkerk rep...@bugs.python.org wrote: _spawn*() and _exec*() are implemented by the C runtime library. spawn*() and execv() are (deprecated) aliases. It is said that execv() is deprecated, but it is not said that it is alias of _execv(). It is only said that _execv() is C++ compliant. http://msdn.microsoft.com/en-us/library/ms235416(v=vs.90).aspx The the first message is about someone's attempt to work around the problems with embedded spaces and double quotes by writing a function to escape each argument. He says he had a partial success. Don't we have such function already? I don't see the problem in quoting the string. Surely this is basic reading comprehension? I am mentally crippled. Sorry about that. Note that on Windows exec*() is useless: it just starts a subprocess and exits the current process. You can use subprocess to get the same effect. Are you describing Windows implementation of _exec() http://msdn.microsoft.com/en-us/library/431x4c1w.aspx or current Python implementation? The Windows implementaion of _exec(). Does it start child process in foreground or in background? Did you compile examples on http://msdn.microsoft.com/en-us/library/431x4c1w.aspx 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. Just use subprocess instead which gets this stuff right. subprocess doesn't replace os.exec*, see issue19060 On Unix subprocess does not replace os.exec*(). That is because on Unix exec*() replaces the current process with a new process with the *same pid*. subprocess cannot do this. But on Windows os.exec*() just starts an independent process with a *different pid* and exits the current process. The line os.execv(path, args) is equivalent to os.spawnv(os.P_NOWAIT, path, args) os._exit(0) 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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19066 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19066] os.execv fails with spaced names on Windows
Richard Oudkerk added the comment: It is said that execv() is deprecated, but it is not said that it is alias of _execv(). It is only said that _execv() is C++ compliant. http://msdn.microsoft.com/en-us/library/ms235416(v=vs.90).aspx Microsoft seems to have decided that all functions in the C runtime which don't begin with an underscore, and are not included in the ANSI C standard should be deprecated. This includes all the fd functions like read(), write(), open(), close(), ... There is no difference in behaviour between these and the underscore versions. ... 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. ... Does it start child process in foreground or in background? Did you compile examples on http://msdn.microsoft.com/en-us/library/431x4c1w.aspx 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. 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. .. 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. This issue should be closed: just use subprocess instead. -- resolution: - duplicate stage: test needed - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19066 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19066] os.execv fails with spaced names on Windows
anatoly techtonik added the comment: Hey. This ticket is about os.execv failing on spaced paths on Windows. It is not a duplicate of issue19124. -- resolution: duplicate - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19066 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19066] os.execv fails with spaced names on Windows
anatoly techtonik added the comment: On Sun, Sep 29, 2013 at 8:48 PM, Richard Oudkerk rep...@bugs.python.org 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? http://msdn.microsoft.com/en-us/library/ms235416(v=vs.90).aspx 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 http://msdn.microsoft.com/en-us/library/431x4c1w.aspx 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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19066 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19066] os.execv fails with spaced names on Windows
Richard Oudkerk added the comment: Hey. This ticket is about os.execv failing on spaced paths on Windows. It is not a duplicate of issue19124. It is a duplicate of #436259 [Windows] exec*/spawn* problem with spaces in args. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19066 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19066] os.execv fails with spaced names on Windows
Changes by Richard Oudkerk shibt...@gmail.com: -- nosy: -sbt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19066 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19066] os.execv fails with spaced names on Windows
Terry J. Reedy added the comment: Reminder: you are not supposed to re-open issues. I agree with Richard that this is a duplicate as submitted. The difference is that we now have subprocess; that is our fix for several problems. I will re-close unless you make a *specific* suggestion for a doc change. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19066 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19066] os.execv fails with spaced names on Windows
Terry J. Reedy added the comment: Please stop marking all versions. Use cntl-left click to select the appropriate ones (currently at most 2.7, 3.3, 3.4 for users). Which version did you run your file with? -- nosy: +loewis, terry.reedy stage: - test needed type: - behavior versions: -Python 2.6, Python 3.1, Python 3.2, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19066 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19066] os.execv fails with spaced names on Windows
New submission from anatoly techtonik: If file to be executed with os.execv on Windows is located in directory with spaces, Python fails. This doesn't fail on Linux. To test, run: testexecv.py spaced testexecv.py is attached. -- components: Library (Lib), Windows files: testexecv.py messages: 198242 nosy: techtonik priority: normal severity: normal status: open title: os.execv fails with spaced names on Windows versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file31837/testexecv.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19066 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
