Eryk Sun <[email protected]> added the comment:
> stdin is closed
> os.open() is called and creates a new fd=0
> a call to os.dup2(fd, 0) is made but is a noop
The dup2() silent noop case is a problem, but not the problem that's reported
in msg411113.
The two examples for this issue are fd.py and fd2.py. In fd.py, "/dev/null" is
opened, and then, if the fd isn't 0, the fd is duped to inheritable fd 0. In
fd2.py, fd 0 is closed, and then "/dev/null" is opened as fd 0, which isn't
inheritable in Python 3.
I think the only problems regarding fd2.py are cross-platform inconsistency
and/or documentation. If a similar example is tested in Windows it actually
works, assuming os.devnull is used and that "sleep.exe" is available (e.g. from
MSYS2). The child's stdin will be the same file as the parent's stdin.
In regard to the standard files, the subprocess documentation states the
following:
With the default settings of None, no redirection will occur;
the child’s file handles will be inherited from the parent.
If close_fds is true, all file descriptors except 0, 1 and 2
will be closed before the child process is executed.
The above applies only to POSIX. It's not wrong in that case, but it should be
emphasized that any of the standard file descriptors that's not overridden has
to be inheritable in POSIX. Also, if overriding to a specific file, the file
descriptor must be inheritable in POSIX. By default, file descriptors for
opened files are not inheritable, so the subprocess documentation should
reference os.set_inheritable().
For Windows it says the following:
if close_fds is true then no handles will be inherited by
the child process unless explicitly passed in the handle_list
element of STARTUPINFO.lpAttributeList, or by standard handle
redirection.
That's mostly right, except the last part about standard handle redirection is
vague. If close_fds is true, none of the standard handles of the current
process is ever inherited in Windows. They could be in principle, but
subprocess wasn't designed that way. When close_fds is true, and the standard
handles aren't overridden, subprocess relies on the OS to duplicate (not
inherit) the standard handles to the child when spawning a console application
(e.g. "python.exe", but not "pythonw.exe"). If at least one is overridden,
subprocess duplicates all three as inheritable handles via _make_inheritable().
(This is a choice. It doesn't have to do this. It could simply ensure that its
own pipe/null files are inheritable.) Thus, when close_fds is true it never
matters whether the current standard handles are inheritable, or whether a
specified override is inheritable. This behavior is in stark contrast to how
subprocess works in POSIX.
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue46454>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
