Skip to content

bpo-42041: Clarify how Windows path search affects virtual environments #22715

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Oct 20, 2020
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 21 additions & 2 deletions Doc/library/subprocess.rst
Original file line number Diff line number Diff line change
Expand Up @@ -344,7 +344,7 @@ functions.
encoding=None, errors=None, text=None)

Execute a child program in a new process. On POSIX, the class uses
:meth:`os.execvp`-like behavior to execute the child program. On Windows,
:meth:`os.execvpe`-like behavior to execute the child program. On Windows,
the class uses the Windows ``CreateProcess()`` function. The arguments to
:class:`Popen` are as follows.

Expand All @@ -356,6 +356,25 @@ functions.
arguments for additional differences from the default behavior. Unless
otherwise stated, it is recommended to pass *args* as a sequence.

.. warning::
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you also change os.execvp to os.execvpe at the beginning of the Popen docs?

Also, further down in the cwd section it claims "In particular, the function looks for executable (or for the first item in args) relative to cwd if the executable path is a relative path". That should be changed to restrict it to just POSIX. You could change "In particular" to "In POSIX".

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.


For maximum reliability, use a fully-qualified path for the executable.
To search for an unqualified name on :envvar:`PATH`, use
:meth:`shutil.which`. On all platforms, passing :data:`sys.executable`
is the recommended way to launch the current Python interpreter again,
and use the ``-m`` command-line format to launch an installed module.

Resolving the path of *executable* (or the first item of *args*) is
platform dependent. For POSIX, see :meth:`os.execvpe`, and note that
when resolving or searching for the executable path, *cwd* overrides the
current working directory and *env* can override the ``PATH``
environment variable. For Windows, see the documentation of the
``lpApplicationName`` and ``lpCommandLine`` parameters of WinAPI
``CreateProcess``, and note that when resolving or searching for the
executable path with ``shell=False``, *cwd* does not override the
current working directory and *env* cannot override the ``PATH``
environment variable. Using a full path avoids all of these variations.

An example of passing some arguments to an external program
as a sequence is::

Expand Down Expand Up @@ -524,7 +543,7 @@ functions.

If *cwd* is not ``None``, the function changes the working directory to
*cwd* before executing the child. *cwd* can be a string, bytes or
:term:`path-like <path-like object>` object. In particular, the function
:term:`path-like <path-like object>` object. In POSIX, the function
looks for *executable* (or for the first item in *args*) relative to *cwd*
if the executable path is a relative path.

Expand Down