[Python-modules-commits] [python-subprocess32] 01/03: Imported Upstream version 3.2.6
Daniel Stender
danstender-guest at moszumanska.debian.org
Tue Sep 1 18:36:20 UTC 2015
This is an automated email from the git hooks/post-receive script.
danstender-guest pushed a commit to branch master
in repository python-subprocess32.
commit eac27f4c2917d923854a809301ad6b46f963fbd4
Author: Daniel Stender <debian at danielstender.com>
Date: Tue Sep 1 20:28:20 2015 +0200
Imported Upstream version 3.2.6
---
ChangeLog | 83 ++
LICENSE | 283 ++++++
MANIFEST.in | 13 +
PKG-INFO | 15 +
README.txt | 16 +
_posixsubprocess.c | 890 +++++++++++++++++++
_posixsubprocess_helpers.c | 163 ++++
setup.cfg | 6 +
setup.py | 37 +
subprocess32.py | 1891 +++++++++++++++++++++++++++++++++++++++
test_subprocess32.py | 2072 +++++++++++++++++++++++++++++++++++++++++++
testdata/fd_status.py | 24 +
testdata/input_reader.py | 7 +
testdata/qcat.py | 7 +
testdata/qgrep.py | 10 +
testdata/sigchild_ignore.py | 18 +
16 files changed, 5535 insertions(+)
diff --git a/ChangeLog b/ChangeLog
new file mode 100644
index 0000000..ff6af02
--- /dev/null
+++ b/ChangeLog
@@ -0,0 +1,83 @@
+-----------------
+2014-04-23 3.2.6
+-----------------
+
+* Fixes issue #21291: Popen.wait() is now thread safe so that multiple
+ threads may be calling wait() or poll() on a Popen instance at the same time
+ without losing the Popen.returncode value.
+* Fixes issue #14396: Handle the odd rare case of waitpid returning 0 when not
+ expected in Popen.wait().
+* Fixes issue #16962: Use getdents64 instead of the obsolete getdents syscall
+ on Linux. Some architectures do not implement the latter.
+
+-----------------
+2013-12-10 3.2.5
+-----------------
+
+* Fixes issue #15798: subprocess.Popen() no longer fails if file
+ descriptor 0, 1 or 2 is closed.
+* Fixes issue #18763: close_fd file descriptors are now closed after
+ any preexec_fn call.
+
+-----------------
+2013-06-15 3.2.5rc1
+-----------------
+
+* Fixes issue #16650 - Don't reference ECHILD from outside the local scope.
+* Unittests no longer spew any test data for human verification to stdout.
+* Remove a bare print to stdout that could have happened if the child process
+ wrote garbage to its pre-exec error pipe.
+* Fixes issue #16327 - the subprocess module no longer leaks file descriptors
+ used for stdin/stdout/stderr pipes to the child when the fork() fails. It
+ also no longer potentially double closes these pipe fds.
+* Correct the Python version check around use of imp_module to specify 2.6.3
+ as the minimum version that exists in. Why is anyone using such an old 2.6?
+* Fixes Issue #16114: The subprocess module no longer provides a misleading
+ error message stating that args[0] did not exist when either the cwd or
+ executable keyword arguments specified a path that did not exist.
+* Add more Popen cwd tests.
+* Handle errno.ECHILD in poll.
+* Don't leak a reference to the gc module on capi use error.
+* Check return value to avoid a crash if the capi were misused.
+* Check result of PyObject_IsTrue().
+* Adds test_universal_newlines_communicate_input_none.
+* Most everything above consists of backports. See the hg logs for their
+ upstream hg.python.org cpython revision numbers.
+
+----------------
+2012-06-10 3.2.3
+----------------
+
+* Fixes the references to the 'surrogateescape' unicode encoding error
+ handler that does not exist in Python 2.x. 'strict' is used so that
+ a UnicodeEncodeError exception is raised in these situations. These
+ MAY occur if your sys.getfilesystemencoding() is not UTF-8 and
+ attempt to use a non-ascii executable, args or env values. Prior to
+ this change, those would result in a hard to debug LookupError for
+ surrogateescape.
+* Issue #15000: Support the "unique" x32 architecture in _posixsubprocess.c.
+* Fix a compilation problem when O_CLOEXEC is not defined.
+
+------------------
+2012-02-18 3.2.3b1
+------------------
+
+This release brings in the last year and a half's worth of bugfixes and
+improvements to Python 3.2's subprocess module:
+
+Off the top of my head, some major bugfix highlights include:
+ * Timeout support on the APIs.
+ * close_fds=True is now the default (as it is in 3.2) and performs much faster.
+ * Fixed EINTR handling.
+ * Fixed SIGCHLD handling.
+ * Fixed several race conditions.
+ * Many more bug fixes too numerous to list.
+
+You can grep out the full list of improvements related to subprocess in:
+ http://hg.python.org/cpython/file/9ce5d456138b/Misc/NEWS
+
+-------------
+2010-06 3.2.0
+-------------
+
+This was the first release. Roughly equivalent to Python 3.2.0a1.
diff --git a/LICENSE b/LICENSE
new file mode 100644
index 0000000..0d33662
--- /dev/null
+++ b/LICENSE
@@ -0,0 +1,283 @@
+A. HISTORY OF THE SOFTWARE
+==========================
+
+Python was created in the early 1990s by Guido van Rossum at Stichting
+Mathematisch Centrum (CWI, see http://www.cwi.nl) in the Netherlands
+as a successor of a language called ABC. Guido remains Python's
+principal author, although it includes many contributions from others.
+
+In 1995, Guido continued his work on Python at the Corporation for
+National Research Initiatives (CNRI, see http://www.cnri.reston.va.us)
+in Reston, Virginia where he released several versions of the
+software.
+
+In May 2000, Guido and the Python core development team moved to
+BeOpen.com to form the BeOpen PythonLabs team. In October of the same
+year, the PythonLabs team moved to Digital Creations (now Zope
+Corporation, see http://www.zope.com). In 2001, the Python Software
+Foundation (PSF, see http://www.python.org/psf/) was formed, a
+non-profit organization created specifically to own Python-related
+Intellectual Property. Zope Corporation is a sponsoring member of
+the PSF.
+
+All Python releases are Open Source (see http://www.opensource.org for
+the Open Source Definition). Historically, most, but not all, Python
+releases have also been GPL-compatible; the table below summarizes
+the various releases.
+
+ Release Derived Year Owner GPL-
+ from compatible? (1)
+
+ 0.9.0 thru 1.2 1991-1995 CWI yes
+ 1.3 thru 1.5.2 1.2 1995-1999 CNRI yes
+ 1.6 1.5.2 2000 CNRI no
+ 2.0 1.6 2000 BeOpen.com no
+ 1.6.1 1.6 2001 CNRI yes (2)
+ 2.1 2.0+1.6.1 2001 PSF no
+ 2.0.1 2.0+1.6.1 2001 PSF yes
+ 2.1.1 2.1+2.0.1 2001 PSF yes
+ 2.2 2.1.1 2001 PSF yes
+ 2.1.2 2.1.1 2002 PSF yes
+ 2.1.3 2.1.2 2002 PSF yes
+ 2.2.1 2.2 2002 PSF yes
+ 2.2.2 2.2.1 2002 PSF yes
+ 2.2.3 2.2.2 2003 PSF yes
+ 2.3 2.2.2 2002-2003 PSF yes
+ 2.3.1 2.3 2002-2003 PSF yes
+ 2.3.2 2.3.1 2002-2003 PSF yes
+ 2.3.3 2.3.2 2002-2003 PSF yes
+ 2.3.4 2.3.3 2004 PSF yes
+ 2.3.5 2.3.4 2005 PSF yes
+ 2.4 2.3 2004 PSF yes
+ 2.4.1 2.4 2005 PSF yes
+ 2.4.2 2.4.1 2005 PSF yes
+ 2.4.3 2.4.2 2006 PSF yes
+ 2.4.4 2.4.3 2006 PSF yes
+ 2.5 2.4 2006 PSF yes
+ 2.5.1 2.5 2007 PSF yes
+ 2.5.2 2.5.1 2008 PSF yes
+ 2.5.3 2.5.2 2008 PSF yes
+ 2.6 2.5 2008 PSF yes
+ 2.6.1 2.6 2008 PSF yes
+ 2.6.2 2.6.1 2009 PSF yes
+ 2.6.3 2.6.2 2009 PSF yes
+ 2.6.4 2.6.3 2009 PSF yes
+ 2.6.5 2.6.4 2010 PSF yes
+ 3.0 2.6 2008 PSF yes
+ 3.0.1 3.0 2009 PSF yes
+ 3.1 3.0.1 2009 PSF yes
+ 3.1.1 3.1 2009 PSF yes
+ 3.1.2 3.1 2010 PSF yes
+
+Footnotes:
+
+(1) GPL-compatible doesn't mean that we're distributing Python under
+ the GPL. All Python licenses, unlike the GPL, let you distribute
+ a modified version without making your changes open source. The
+ GPL-compatible licenses make it possible to combine Python with
+ other software that is released under the GPL; the others don't.
+
+(2) According to Richard Stallman, 1.6.1 is not GPL-compatible,
+ because its license has a choice of law clause. According to
+ CNRI, however, Stallman's lawyer has told CNRI's lawyer that 1.6.1
+ is "not incompatible" with the GPL.
+
+Thanks to the many outside volunteers who have worked under Guido's
+direction to make these releases possible.
+
+
+B. TERMS AND CONDITIONS FOR ACCESSING OR OTHERWISE USING PYTHON
+===============================================================
+
+PYTHON SOFTWARE FOUNDATION LICENSE VERSION 2
+--------------------------------------------
+
+1. This LICENSE AGREEMENT is between the Python Software Foundation
+("PSF"), and the Individual or Organization ("Licensee") accessing and
+otherwise using this software ("Python") in source or binary form and
+its associated documentation.
+
+2. Subject to the terms and conditions of this License Agreement, PSF hereby
+grants Licensee a nonexclusive, royalty-free, world-wide license to reproduce,
+analyze, test, perform and/or display publicly, prepare derivative works,
+distribute, and otherwise use Python alone or in any derivative version,
+provided, however, that PSF's License Agreement and PSF's notice of copyright,
+i.e., "Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
+Python Software Foundation; All Rights Reserved" are retained in Python alone or
+in any derivative version prepared by Licensee.
+
+3. In the event Licensee prepares a derivative work that is based on
+or incorporates Python or any part thereof, and wants to make
+the derivative work available to others as provided herein, then
+Licensee hereby agrees to include in any such work a brief summary of
+the changes made to Python.
+
+4. PSF is making Python available to Licensee on an "AS IS"
+basis. PSF MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR
+IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, PSF MAKES NO AND
+DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS
+FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON WILL NOT
+INFRINGE ANY THIRD PARTY RIGHTS.
+
+5. PSF SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON
+FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS
+A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON,
+OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF.
+
+6. This License Agreement will automatically terminate upon a material
+breach of its terms and conditions.
+
+7. Nothing in this License Agreement shall be deemed to create any
+relationship of agency, partnership, or joint venture between PSF and
+Licensee. This License Agreement does not grant permission to use PSF
+trademarks or trade name in a trademark sense to endorse or promote
+products or services of Licensee, or any third party.
+
+8. By copying, installing or otherwise using Python, Licensee
+agrees to be bound by the terms and conditions of this License
+Agreement.
+
+
+BEOPEN.COM LICENSE AGREEMENT FOR PYTHON 2.0
+-------------------------------------------
+
+BEOPEN PYTHON OPEN SOURCE LICENSE AGREEMENT VERSION 1
+
+1. This LICENSE AGREEMENT is between BeOpen.com ("BeOpen"), having an
+office at 160 Saratoga Avenue, Santa Clara, CA 95051, and the
+Individual or Organization ("Licensee") accessing and otherwise using
+this software in source or binary form and its associated
+documentation ("the Software").
+
+2. Subject to the terms and conditions of this BeOpen Python License
+Agreement, BeOpen hereby grants Licensee a non-exclusive,
+royalty-free, world-wide license to reproduce, analyze, test, perform
+and/or display publicly, prepare derivative works, distribute, and
+otherwise use the Software alone or in any derivative version,
+provided, however, that the BeOpen Python License is retained in the
+Software, alone or in any derivative version prepared by Licensee.
+
+3. BeOpen is making the Software available to Licensee on an "AS IS"
+basis. BEOPEN MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR
+IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, BEOPEN MAKES NO AND
+DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS
+FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE SOFTWARE WILL NOT
+INFRINGE ANY THIRD PARTY RIGHTS.
+
+4. BEOPEN SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF THE
+SOFTWARE FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS
+AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE SOFTWARE, OR ANY
+DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF.
+
+5. This License Agreement will automatically terminate upon a material
+breach of its terms and conditions.
+
+6. This License Agreement shall be governed by and interpreted in all
+respects by the law of the State of California, excluding conflict of
+law provisions. Nothing in this License Agreement shall be deemed to
+create any relationship of agency, partnership, or joint venture
+between BeOpen and Licensee. This License Agreement does not grant
+permission to use BeOpen trademarks or trade names in a trademark
+sense to endorse or promote products or services of Licensee, or any
+third party. As an exception, the "BeOpen Python" logos available at
+http://www.pythonlabs.com/logos.html may be used according to the
+permissions granted on that web page.
+
+7. By copying, installing or otherwise using the software, Licensee
+agrees to be bound by the terms and conditions of this License
+Agreement.
+
+
+CNRI LICENSE AGREEMENT FOR PYTHON 1.6.1
+---------------------------------------
+
+1. This LICENSE AGREEMENT is between the Corporation for National
+Research Initiatives, having an office at 1895 Preston White Drive,
+Reston, VA 20191 ("CNRI"), and the Individual or Organization
+("Licensee") accessing and otherwise using Python 1.6.1 software in
+source or binary form and its associated documentation.
+
+2. Subject to the terms and conditions of this License Agreement, CNRI
+hereby grants Licensee a nonexclusive, royalty-free, world-wide
+license to reproduce, analyze, test, perform and/or display publicly,
+prepare derivative works, distribute, and otherwise use Python 1.6.1
+alone or in any derivative version, provided, however, that CNRI's
+License Agreement and CNRI's notice of copyright, i.e., "Copyright (c)
+1995-2001 Corporation for National Research Initiatives; All Rights
+Reserved" are retained in Python 1.6.1 alone or in any derivative
+version prepared by Licensee. Alternately, in lieu of CNRI's License
+Agreement, Licensee may substitute the following text (omitting the
+quotes): "Python 1.6.1 is made available subject to the terms and
+conditions in CNRI's License Agreement. This Agreement together with
+Python 1.6.1 may be located on the Internet using the following
+unique, persistent identifier (known as a handle): 1895.22/1013. This
+Agreement may also be obtained from a proxy server on the Internet
+using the following URL: http://hdl.handle.net/1895.22/1013".
+
+3. In the event Licensee prepares a derivative work that is based on
+or incorporates Python 1.6.1 or any part thereof, and wants to make
+the derivative work available to others as provided herein, then
+Licensee hereby agrees to include in any such work a brief summary of
+the changes made to Python 1.6.1.
+
+4. CNRI is making Python 1.6.1 available to Licensee on an "AS IS"
+basis. CNRI MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR
+IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, CNRI MAKES NO AND
+DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS
+FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON 1.6.1 WILL NOT
+INFRINGE ANY THIRD PARTY RIGHTS.
+
+5. CNRI SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON
+1.6.1 FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS
+A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON 1.6.1,
+OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF.
+
+6. This License Agreement will automatically terminate upon a material
+breach of its terms and conditions.
+
+7. This License Agreement shall be governed by the federal
+intellectual property law of the United States, including without
+limitation the federal copyright law, and, to the extent such
+U.S. federal law does not apply, by the law of the Commonwealth of
+Virginia, excluding Virginia's conflict of law provisions.
+Notwithstanding the foregoing, with regard to derivative works based
+on Python 1.6.1 that incorporate non-separable material that was
+previously distributed under the GNU General Public License (GPL), the
+law of the Commonwealth of Virginia shall govern this License
+Agreement only as to issues arising under or with respect to
+Paragraphs 4, 5, and 7 of this License Agreement. Nothing in this
+License Agreement shall be deemed to create any relationship of
+agency, partnership, or joint venture between CNRI and Licensee. This
+License Agreement does not grant permission to use CNRI trademarks or
+trade name in a trademark sense to endorse or promote products or
+services of Licensee, or any third party.
+
+8. By clicking on the "ACCEPT" button where indicated, or by copying,
+installing or otherwise using Python 1.6.1, Licensee agrees to be
+bound by the terms and conditions of this License Agreement.
+
+ ACCEPT
+
+
+CWI LICENSE AGREEMENT FOR PYTHON 0.9.0 THROUGH 1.2
+--------------------------------------------------
+
+Copyright (c) 1991 - 1995, Stichting Mathematisch Centrum Amsterdam,
+The Netherlands. All rights reserved.
+
+Permission to use, copy, modify, and distribute this software and its
+documentation for any purpose and without fee is hereby granted,
+provided that the above copyright notice appear in all copies and that
+both that copyright notice and this permission notice appear in
+supporting documentation, and that the name of Stichting Mathematisch
+Centrum or CWI not be used in advertising or publicity pertaining to
+distribution of the software without specific, written prior
+permission.
+
+STICHTING MATHEMATISCH CENTRUM DISCLAIMS ALL WARRANTIES WITH REGARD TO
+THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+FITNESS, IN NO EVENT SHALL STICHTING MATHEMATISCH CENTRUM BE LIABLE
+FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
+OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
diff --git a/MANIFEST.in b/MANIFEST.in
new file mode 100644
index 0000000..8b7b39a
--- /dev/null
+++ b/MANIFEST.in
@@ -0,0 +1,13 @@
+include *.txt
+include LICENSE*
+include setup.py
+include setup.cfg
+include ChangeLog
+include MANIFEST.in
+
+include *.c *.h *.py
+include testdata/*
+
+prune build
+prune dist
+prune .hg*
diff --git a/PKG-INFO b/PKG-INFO
new file mode 100644
index 0000000..48cfc1d
--- /dev/null
+++ b/PKG-INFO
@@ -0,0 +1,15 @@
+Metadata-Version: 1.0
+Name: subprocess32
+Version: 3.2.6
+Summary: Backport of the subprocess module from Python 3.2/3.3 for use on 2.x.
+Home-page: http://code.google.com/p/python-subprocess32/
+Author: Gregory P. Smith
+Author-email: greg at krypto.org
+License: PSF license
+Description:
+ This is a backport of the subprocess standard library module from
+ Python 3.2 & 3.3 for use on Python 2.4, 2.5, 2.6 and 2.7.
+ It includes bugfixes and new features. On POSIX systems it is
+ guaranteed to be reliable when used in threaded applications.
+ Bonus: It includes timeout support from Python 3.3.
+Platform: UNKNOWN
diff --git a/README.txt b/README.txt
new file mode 100644
index 0000000..8608e7d
--- /dev/null
+++ b/README.txt
@@ -0,0 +1,16 @@
+This is a backport of the Python 3.2 subprocess module for use on
+Python versions 2.4 through 2.7.
+
+It includes many important bug fixes including a C extension module used
+internally to handle the code path between fork() and exec(). This version
+is reliable when an application is using threads.
+
+Refer to the Python 3.2 documentation for usage information:
+ http://docs.python.org/3.2/library/subprocess.html
+
+Timeout support backported from Python 3.3 is also included.
+
+Bugs? Try to reproduce them on the latest Python 3.x itself and file bug
+reports on http://bugs.python.org/. Add gregory.p.smith to the Nosy list.
+
+-- Gregory P. Smith greg at krypto.org
diff --git a/_posixsubprocess.c b/_posixsubprocess.c
new file mode 100644
index 0000000..cd63054
--- /dev/null
+++ b/_posixsubprocess.c
@@ -0,0 +1,890 @@
+/* Authors: Gregory P. Smith & Jeffrey Yasskin */
+#define PY_SSIZE_T_CLEAN
+#include "Python.h"
+#if defined(__linux__) && !defined(HAVE_PIPE2)
+# define HAVE_PIPE2 1 /* From 3.2's configure script, undef if you don't. */
+#endif
+#if defined(HAVE_PIPE2) && !defined(_GNU_SOURCE)
+# define _GNU_SOURCE
+#endif
+#include <unistd.h>
+#include <fcntl.h>
+#ifdef __linux__
+# define HAVE_SYS_TYPES_H 1 /* From 3.2's configure script, undef if reqd. */
+# define HAVE_SYS_SYSCALL_H 1 /* From 3.2's configure script, undef if reqd. */
+# define HAVE_SYS_DIRENT_H 1 /* From 3.2's configure script, undef if reqd. */
+#endif
+#ifdef HAVE_SYS_TYPES_H
+#include <sys/types.h>
+#endif
+#if defined(HAVE_SYS_STAT_H) && defined(__FreeBSD__)
+#include <sys/stat.h>
+#endif
+#ifdef HAVE_SYS_SYSCALL_H
+#include <sys/syscall.h>
+#endif
+#ifdef HAVE_DIRENT_H
+#include <dirent.h>
+#endif
+
+#if defined(__ANDROID__) && !defined(SYS_getdents64)
+/* Android doesn't expose syscalls, add the definition manually. */
+# include <sys/linux-syscalls.h>
+# define SYS_getdents64 __NR_getdents64
+#endif
+
+#include "_posixsubprocess_helpers.c"
+
+#if (PY_VERSION_HEX < 0x02060300)
+/* These are not public API fuctions until 2.6.3. */
+static void _PyImport_AcquireLock(void);
+static int _PyImport_ReleaseLock(void);
+#endif
+
+#if defined(sun)
+/* readdir64 is used to work around Solaris 9 bug 6395699. */
+# define readdir readdir64
+# define dirent dirent64
+# if !defined(HAVE_DIRFD)
+/* Some versions of Solaris lack dirfd(). */
+# define dirfd(dirp) ((dirp)->dd_fd)
+# define HAVE_DIRFD
+# endif
+#endif
+
+#if defined(__FreeBSD__) || (defined(__APPLE__) && defined(__MACH__))
+# define FD_DIR "/dev/fd"
+#else
+# define FD_DIR "/proc/self/fd"
+#endif
+
+#define POSIX_CALL(call) if ((call) == -1) goto error
+
+
+/* Maximum file descriptor, initialized on module load. */
+static long max_fd;
+
+
+/* Given the gc module call gc.enable() and return 0 on success. */
+static int
+_enable_gc(PyObject *gc_module)
+{
+ PyObject *result;
+ result = PyObject_CallMethod(gc_module, "enable", NULL);
+ if (result == NULL)
+ return 1;
+ Py_DECREF(result);
+ return 0;
+}
+
+
+/* Convert ASCII to a positive int, no libc call. no overflow. -1 on error. */
+static int
+_pos_int_from_ascii(char *name)
+{
+ int num = 0;
+ while (*name >= '0' && *name <= '9') {
+ num = num * 10 + (*name - '0');
+ ++name;
+ }
+ if (*name)
+ return -1; /* Non digit found, not a number. */
+ return num;
+}
+
+
+#if defined(__FreeBSD__)
+/* When /dev/fd isn't mounted it is often a static directory populated
+ * with 0 1 2 or entries for 0 .. 63 on FreeBSD, NetBSD and OpenBSD.
+ * NetBSD and OpenBSD have a /proc fs available (though not necessarily
+ * mounted) and do not have fdescfs for /dev/fd. MacOS X has a devfs
+ * that properly supports /dev/fd.
+ */
+static int
+_is_fdescfs_mounted_on_dev_fd()
+{
+ struct stat dev_stat;
+ struct stat dev_fd_stat;
+ if (stat("/dev", &dev_stat) != 0)
+ return 0;
+ if (stat(FD_DIR, &dev_fd_stat) != 0)
+ return 0;
+ if (dev_stat.st_dev == dev_fd_stat.st_dev)
+ return 0; /* / == /dev == /dev/fd means it is static. #fail */
+ return 1;
+}
+#endif
+
+
+/* Returns 1 if there is a problem with fd_sequence, 0 otherwise. */
+static int
+_sanity_check_python_fd_sequence(PyObject *fd_sequence)
+{
+ Py_ssize_t seq_idx, seq_len = PySequence_Length(fd_sequence);
+ long prev_fd = -1;
+ for (seq_idx = 0; seq_idx < seq_len; ++seq_idx) {
+ PyObject* py_fd = PySequence_Fast_GET_ITEM(fd_sequence, seq_idx);
+ long iter_fd = PyLong_AsLong(py_fd);
+ if (iter_fd < 0 || iter_fd < prev_fd || iter_fd > INT_MAX) {
+ /* Negative, overflow, not a Long, unsorted, too big for a fd. */
+ return 1;
+ }
+ }
+ return 0;
+}
+
+
+/* Is fd found in the sorted Python Sequence? */
+static int
+_is_fd_in_sorted_fd_sequence(int fd, PyObject *fd_sequence)
+{
+ /* Binary search. */
+ Py_ssize_t search_min = 0;
+ Py_ssize_t search_max = PySequence_Length(fd_sequence) - 1;
+ if (search_max < 0)
+ return 0;
+ do {
+ long middle = (search_min + search_max) / 2;
+ long middle_fd = PyLong_AsLong(
+ PySequence_Fast_GET_ITEM(fd_sequence, middle));
+ if (fd == middle_fd)
+ return 1;
+ if (fd > middle_fd)
+ search_min = middle + 1;
+ else
+ search_max = middle - 1;
+ } while (search_min <= search_max);
+ return 0;
+}
+
+
+/* Close all file descriptors in the range start_fd inclusive to
+ * end_fd exclusive except for those in py_fds_to_keep. If the
+ * range defined by [start_fd, end_fd) is large this will take a
+ * long time as it calls close() on EVERY possible fd.
+ */
+static void
+_close_fds_by_brute_force(int start_fd, int end_fd, PyObject *py_fds_to_keep)
+{
+ Py_ssize_t num_fds_to_keep = PySequence_Length(py_fds_to_keep);
+ Py_ssize_t keep_seq_idx;
+ int fd_num;
+ /* As py_fds_to_keep is sorted we can loop through the list closing
+ * fds inbetween any in the keep list falling within our range. */
+ for (keep_seq_idx = 0; keep_seq_idx < num_fds_to_keep; ++keep_seq_idx) {
+ PyObject* py_keep_fd = PySequence_Fast_GET_ITEM(py_fds_to_keep,
+ keep_seq_idx);
+ int keep_fd = PyLong_AsLong(py_keep_fd);
+ if (keep_fd < start_fd)
+ continue;
+ for (fd_num = start_fd; fd_num < keep_fd; ++fd_num) {
+ while (close(fd_num) < 0 && errno == EINTR);
+ }
+ start_fd = keep_fd + 1;
+ }
+ if (start_fd <= end_fd) {
+ for (fd_num = start_fd; fd_num < end_fd; ++fd_num) {
+ while (close(fd_num) < 0 && errno == EINTR);
+ }
+ }
+}
+
+
+#if defined(__linux__) && defined(HAVE_SYS_SYSCALL_H)
+/* It doesn't matter if d_name has room for NAME_MAX chars; we're using this
+ * only to read a directory of short file descriptor number names. The kernel
+ * will return an error if we didn't give it enough space. Highly Unlikely.
+ * This structure is very old and stable: It will not change unless the kernel
+ * chooses to break compatibility with all existing binaries. Highly Unlikely.
+ */
+struct linux_dirent64 {
+ unsigned long long d_ino;
+ long long d_off;
+ unsigned short d_reclen; /* Length of this linux_dirent */
+ unsigned char d_type;
+ char d_name[256]; /* Filename (null-terminated) */
+};
+
+/* Close all open file descriptors in the range start_fd inclusive to end_fd
+ * exclusive. Do not close any in the sorted py_fds_to_keep list.
+ *
+ * This version is async signal safe as it does not make any unsafe C library
+ * calls, malloc calls or handle any locks. It is _unfortunate_ to be forced
+ * to resort to making a kernel system call directly but this is the ONLY api
+ * available that does no harm. opendir/readdir/closedir perform memory
+ * allocation and locking so while they usually work they are not guaranteed
+ * to (especially if you have replaced your malloc implementation). A version
+ * of this function that uses those can be found in the _maybe_unsafe variant.
+ *
+ * This is Linux specific because that is all I am ready to test it on. It
+ * should be easy to add OS specific dirent or dirent64 structures and modify
+ * it with some cpp #define magic to work on other OSes as well if you want.
+ */
+static void
+_close_open_fd_range_safe(int start_fd, int end_fd, PyObject* py_fds_to_keep)
+{
+ int fd_dir_fd;
+ if (start_fd >= end_fd)
+ return;
+#ifdef O_CLOEXEC
+ fd_dir_fd = open(FD_DIR, O_RDONLY | O_CLOEXEC, 0);
+#else
+ fd_dir_fd = open(FD_DIR, O_RDONLY, 0);
+#ifdef FD_CLOEXEC
+ {
+ int old = fcntl(fd_dir_fd, F_GETFD);
+ if (old != -1)
+ fcntl(fd_dir_fd, F_SETFD, old | FD_CLOEXEC);
+ }
+#endif
+#endif
+ if (fd_dir_fd == -1) {
+ /* No way to get a list of open fds. */
+ _close_fds_by_brute_force(start_fd, end_fd, py_fds_to_keep);
+ return;
+ } else {
+ char buffer[sizeof(struct linux_dirent64)];
+ int bytes;
+ while ((bytes = syscall(SYS_getdents64, fd_dir_fd,
+ (struct linux_dirent64 *)buffer,
+ sizeof(buffer))) > 0) {
+ struct linux_dirent64 *entry;
+ int offset;
+ for (offset = 0; offset < bytes; offset += entry->d_reclen) {
+ int fd;
+ entry = (struct linux_dirent64 *)(buffer + offset);
+ if ((fd = _pos_int_from_ascii(entry->d_name)) < 0)
+ continue; /* Not a number. */
+ if (fd != fd_dir_fd && fd >= start_fd && fd < end_fd &&
+ !_is_fd_in_sorted_fd_sequence(fd, py_fds_to_keep)) {
+ while (close(fd) < 0 && errno == EINTR);
+ }
+ }
+ }
+ close(fd_dir_fd);
+ }
+}
+
+#define _close_open_fd_range _close_open_fd_range_safe
+
+#else /* NOT (defined(__linux__) && defined(HAVE_SYS_SYSCALL_H)) */
+
+
+/* Close all open file descriptors in the range start_fd inclusive to end_fd
+ * exclusive. Do not close any in the sorted py_fds_to_keep list.
+ *
+ * This function violates the strict use of async signal safe functions. :(
+ * It calls opendir(), readdir() and closedir(). Of these, the one most
+ * likely to ever cause a problem is opendir() as it performs an internal
+ * malloc(). Practically this should not be a problem. The Java VM makes the
+ * same calls between fork and exec in its own UNIXProcess_md.c implementation.
+ *
+ * readdir_r() is not used because it provides no benefit. It is typically
+ * implemented as readdir() followed by memcpy(). See also:
+ * http://womble.decadent.org.uk/readdir_r-advisory.html
+ */
+static void
+_close_open_fd_range_maybe_unsafe(int start_fd, int end_fd,
+ PyObject* py_fds_to_keep)
+{
+ DIR *proc_fd_dir;
+#ifndef HAVE_DIRFD
+ while (_is_fd_in_sorted_fd_sequence(start_fd, py_fds_to_keep) &&
+ (start_fd < end_fd)) {
+ ++start_fd;
+ }
+ if (start_fd >= end_fd)
+ return;
+ /* Close our lowest fd before we call opendir so that it is likely to
+ * reuse that fd otherwise we might close opendir's file descriptor in
+ * our loop. This trick assumes that fd's are allocated on a lowest
+ * available basis. */
+ while (close(start_fd) < 0 && errno == EINTR);
+ ++start_fd;
+#endif
+ if (start_fd >= end_fd)
+ return;
+
+#if defined(__FreeBSD__)
+ if (!_is_fdescfs_mounted_on_dev_fd())
+ proc_fd_dir = NULL;
+ else
+#endif
+ proc_fd_dir = opendir(FD_DIR);
+ if (!proc_fd_dir) {
+ /* No way to get a list of open fds. */
+ _close_fds_by_brute_force(start_fd, end_fd, py_fds_to_keep);
+ } else {
+ struct dirent *dir_entry;
+#ifdef HAVE_DIRFD
+ int fd_used_by_opendir = dirfd(proc_fd_dir);
+#else
+ int fd_used_by_opendir = start_fd - 1;
+#endif
+ errno = 0;
+ while ((dir_entry = readdir(proc_fd_dir))) {
+ int fd;
+ if ((fd = _pos_int_from_ascii(dir_entry->d_name)) < 0)
+ continue; /* Not a number. */
+ if (fd != fd_used_by_opendir && fd >= start_fd && fd < end_fd &&
+ !_is_fd_in_sorted_fd_sequence(fd, py_fds_to_keep)) {
+ while (close(fd) < 0 && errno == EINTR);
+ }
+ errno = 0;
+ }
+ if (errno) {
+ /* readdir error, revert behavior. Highly Unlikely. */
+ _close_fds_by_brute_force(start_fd, end_fd, py_fds_to_keep);
+ }
+ closedir(proc_fd_dir);
+ }
+}
+
+#define _close_open_fd_range _close_open_fd_range_maybe_unsafe
+
+#endif /* else NOT (defined(__linux__) && defined(HAVE_SYS_SYSCALL_H)) */
+
+
+/*
+ * This function is code executed in the child process immediately after fork
+ * to set things up and call exec().
+ *
+ * All of the code in this function must only use async-signal-safe functions,
+ * listed at `man 7 signal` or
+ * http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html.
+ *
+ * This restriction is documented at
+ * http://www.opengroup.org/onlinepubs/009695399/functions/fork.html.
+ */
+static void
+child_exec(char *const exec_array[],
+ char *const argv[],
+ char *const envp[],
+ const char *cwd,
+ int p2cread, int p2cwrite,
+ int c2pread, int c2pwrite,
+ int errread, int errwrite,
+ int errpipe_read, int errpipe_write,
+ int close_fds, int restore_signals,
+ int call_setsid,
+ PyObject *py_fds_to_keep,
+ PyObject *preexec_fn,
+ PyObject *preexec_fn_args_tuple)
+{
+ int i, saved_errno, unused, reached_preexec = 0;
+ PyObject *result;
+ const char* err_msg = "";
+ /* Buffer large enough to hold a hex integer. We can't malloc. */
+ char hex_errno[sizeof(saved_errno)*2+1];
+
+ /* Close parent's pipe ends. */
+ if (p2cwrite != -1) {
+ POSIX_CALL(close(p2cwrite));
+ }
+ if (c2pread != -1) {
+ POSIX_CALL(close(c2pread));
+ }
+ if (errread != -1) {
+ POSIX_CALL(close(errread));
+ }
+ POSIX_CALL(close(errpipe_read));
+
+ /* When duping fds, if there arises a situation where one of the fds is
+ either 0, 1 or 2, it is possible that it is overwritten (#12607). */
+ if (c2pwrite == 0)
+ POSIX_CALL(c2pwrite = dup(c2pwrite));
+ if (errwrite == 0 || errwrite == 1)
+ POSIX_CALL(errwrite = dup(errwrite));
+
+ /* Dup fds for child.
+ dup2() removes the CLOEXEC flag but we must do it ourselves if dup2()
+ would be a no-op (issue #10806). */
+ if (p2cread == 0) {
+ int old = fcntl(p2cread, F_GETFD);
+ if (old != -1)
+ fcntl(p2cread, F_SETFD, old & ~FD_CLOEXEC);
+ } else if (p2cread != -1) {
+ POSIX_CALL(dup2(p2cread, 0)); /* stdin */
+ }
+ if (c2pwrite == 1) {
+ int old = fcntl(c2pwrite, F_GETFD);
+ if (old != -1)
+ fcntl(c2pwrite, F_SETFD, old & ~FD_CLOEXEC);
+ } else if (c2pwrite != -1) {
+ POSIX_CALL(dup2(c2pwrite, 1)); /* stdout */
+ }
+ if (errwrite == 2) {
+ int old = fcntl(errwrite, F_GETFD);
+ if (old != -1)
+ fcntl(errwrite, F_SETFD, old & ~FD_CLOEXEC);
+ } else if (errwrite != -1) {
+ POSIX_CALL(dup2(errwrite, 2)); /* stderr */
+ }
+
+ /* Close pipe fds. Make sure we don't close the same fd more than */
+ /* once, or standard fds. */
+ if (p2cread > 2) {
+ POSIX_CALL(close(p2cread));
+ }
+ if (c2pwrite > 2 && c2pwrite != p2cread) {
+ POSIX_CALL(close(c2pwrite));
+ }
+ if (errwrite != c2pwrite && errwrite != p2cread && errwrite > 2) {
+ POSIX_CALL(close(errwrite));
+ }
+
+ if (cwd)
+ POSIX_CALL(chdir(cwd));
+
+ if (restore_signals)
+ _Py_RestoreSignals();
+
+#ifdef HAVE_SETSID
+ if (call_setsid)
+ POSIX_CALL(setsid());
+#endif
+
+ reached_preexec = 1;
+ if (preexec_fn != Py_None && preexec_fn_args_tuple) {
+ /* This is where the user has asked us to deadlock their program. */
+ result = PyObject_Call(preexec_fn, preexec_fn_args_tuple, NULL);
+ if (result == NULL) {
+ /* Stringifying the exception or traceback would involve
+ * memory allocation and thus potential for deadlock.
+ * We've already faced potential deadlock by calling back
+ * into Python in the first place, so it probably doesn't
+ * matter but we avoid it to minimize the possibility. */
+ err_msg = "Exception occurred in preexec_fn.";
+ errno = 0; /* We don't want to report an OSError. */
+ goto error;
+ }
+ /* Py_DECREF(result); - We're about to exec so why bother? */
+ }
+
+ if (close_fds) {
+ int local_max_fd = max_fd;
+#if defined(__NetBSD__)
+ local_max_fd = fcntl(0, F_MAXFD);
+ if (local_max_fd < 0)
+ local_max_fd = max_fd;
+#endif
+ /* TODO HP-UX could use pstat_getproc() if anyone cares about it. */
+ _close_open_fd_range(3, local_max_fd, py_fds_to_keep);
+ }
+
+ /* This loop matches the Lib/os.py _execvpe()'s PATH search when */
+ /* given the executable_list generated by Lib/subprocess.py. */
+ saved_errno = 0;
+ for (i = 0; exec_array[i] != NULL; ++i) {
+ const char *executable = exec_array[i];
+ if (envp) {
+ execve(executable, argv, envp);
+ } else {
+ execv(executable, argv);
+ }
+ if (errno != ENOENT && errno != ENOTDIR && saved_errno == 0) {
+ saved_errno = errno;
+ }
+ }
+ /* Report the first exec error, not the last. */
+ if (saved_errno)
+ errno = saved_errno;
+
+error:
+ saved_errno = errno;
+ /* Report the posix error to our parent process. */
+ /* We ignore all write() return values as the total size of our writes is
+ * less than PIPEBUF and we cannot do anything about an error anyways. */
+ if (saved_errno) {
+ char *cur;
+ unused = write(errpipe_write, "OSError:", 8);
+ cur = hex_errno + sizeof(hex_errno);
+ while (saved_errno != 0 && cur > hex_errno) {
+ *--cur = "0123456789ABCDEF"[saved_errno % 16];
+ saved_errno /= 16;
+ }
+ unused = write(errpipe_write, cur, hex_errno + sizeof(hex_errno) - cur);
+ unused = write(errpipe_write, ":", 1);
+ if (!reached_preexec) {
+ /* Indicate to the parent that the error happened before exec(). */
+ unused = write(errpipe_write, "noexec", 6);
+ }
+ /* We can't call strerror(saved_errno). It is not async signal safe.
+ * The parent process will look the error message up. */
+ } else {
+ unused = write(errpipe_write, "RuntimeError:0:", 15);
+ unused = write(errpipe_write, err_msg, strlen(err_msg));
+ }
+ if (unused) return; /* silly? yes! avoids gcc compiler warning. */
+}
+
+
+static PyObject *
+subprocess_fork_exec(PyObject* self, PyObject *args)
+{
+ PyObject *gc_module = NULL;
+ PyObject *executable_list, *py_close_fds, *py_fds_to_keep;
+ PyObject *env_list, *preexec_fn;
+ PyObject *process_args, *converted_args = NULL, *fast_args = NULL;
+ PyObject *preexec_fn_args_tuple = NULL;
+ int p2cread, p2cwrite, c2pread, c2pwrite, errread, errwrite;
... 4655 lines suppressed ...
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/python-modules/packages/python-subprocess32.git
More information about the Python-modules-commits
mailing list