Hi, I would say it is not safe: f=file("hello") from os import fork, execl if fork()!=0: execl("python", "python" ) This leaves fd=3 open on linux On Wed, Oct 20, 2004 at 03:10:28PM +0200, Peter Astrand wrote: > > Comments? Is it safe or not to assume that by the time the Python has > started, only fds 0,1,2 are open? > > /Peter > > > I think this is the core of the problem. The test_close_fds > > test works like this: > > > > All file descriptors in the forked child (except 0,1,2) are > > closed. Then the Python binary is executed via execvp(). A > > small test program is passed to the Python binary via the -c > > command line option. If the OS and subprocess module works > > correctly, we can be sure of that by the time of the > > execve() system call, only file descriptors (0,1,2) are open > > (well, the errpipe as well, but let's leave that out for > > now). But, by the time the Python binary starts executing > > the small program, all sorts of things may have happened. > > I'm not really sure we can trust Python not to open files > > during startup. For example, if we have a PYTHONSTARTUP > > file, that open file will have a file descriptor, perhaps 3. > > > > On one hand, this bug could indicate a bug in the Python > > interpreter itself: perhaps a file descriptor leak. On the > > other hand, this test might be a bit too unsafe. > > > > So probably, this test should be removed. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/ludal%40logilab.fr > -- Ludovic Aubry LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4