Eryk Sun <eryk...@gmail.com> added the comment:
Steve, what do you think about os.exec*()? Should it be emulated better or deprecated? We can't hide the reality that it's a new process with a different process ID and parent process ID -- against what POSIX requires. But emulating exec() is probably good enough for most cases, especially if code expects to work in Windows. > I like the idea, but we shouldn't invert the dependencies like that. > nt/os is a lower-level library, and should provide its own > implementation (that perhaps subprocess could then use). The precedent I had in mind is os.popen(), which uses subprocess. There wouldn't be much need to implement system() and spawnv[e] if ucrt used PROC_THREAD_ATTRIBUTE_HANDLE_LIST in the common spawn code (exec\spawnv.cpp). Any chance that's in development or planned? If Python implements its own system() and spawnv[e]() functions, support for inheritable file descriptors [1] would probably have to be dropped. That's not a great loss, IMO, but I'm sure someone will be unhappy about it. The problem is that the flags for an open fd (e.g. FDEV, FPIPE, FAPPEND, FTEXT, FNOINHERIT), which the CRT copies to the STARTUPINFO.lpReserved2 buffer, are not public data. In particular, the FAPPEND flag for an O_APPEND open can't be determined or inferred. --- [1] Making an fd inheritable currently requires two steps in Windows Python: fd2 = os.dup(fd); os.set_inheritable(fd2, True). os.dup(fd) creates a duplicate fd that's not flagged FNOINHERIT, but the underlying OS handle isn't inheritable. os.set_inheritable(fd, True) makes the OS handle inheritable, but it can't remove the FNOINHERIT fd flag. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue19124> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
