2013/7/28 Charles-François Natali <cf.nat...@gmail.com>: > 2013/7/28 Antoine Pitrou <solip...@pitrou.net>: >>> (C) Should we handle standard streams (0: stdin, 1: stdout, 2: stderr) >>> differently? For example, os.dup2(fd, 0) should make the file >>> descriptor 0 (stdin) inheritable or non-inheritable? On Windows, >>> os.set_inheritable(fd, False) fails (error 87, invalid argument) on >>> standard streams (0, 1, 2) and copies of the standard streams (created >>> by os.dup()). >> >> I have been advocating for that, but I now realize that special-casing >> these three descriptors in a myriad of fd-creating functions isn't very >> attractive. >> (if a standard stream fd has been closed, any fd-creating function can >> re-create that fd: including socket.socket(), etc.)
>> So perhaps only the *original* standard streams should be left >> inheritable? I plan to only change functions *creating* (and replacing) new file descriptors. Existing file descriptors (like 0, 1, 2) are unchanged. > Having stdin/stdout/stderr cloexec (e.g. after a dup() to redirect to > a log file, a socket...) will likely break a lot of code, e.g. code > using os.system(), or code calling exec manually (and I'm sure there's > a bunch of it). I propose to add just one special case os.dup2(fd, fd2): if fd2 < 3, fd2 is set to inheritable (otherwise, fd2 is set to non-inheritable). os.dup2() is commonly used to replace stdin, stdout and stderr between fork and exec. The http.server (cgi server) and pty modules use dup2() for example http://hg.python.org/features/pep-446/rev/f8a52518be4c Victor _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
