[issue15533] subprocess.Popen(cwd) documentation: Posix vs Windows

Eryk Sun added the comment: > I don't understand the wording proposed (that seem backwards to me?) Thanks. Looks like I inverted the logic of the quoted paragraph. It should have been a "relative path with a slash in it" is resolved against the current working directory, not "without a

[issue15533] subprocess.Popen(cwd) documentation: Posix vs Windows

ban added the comment: >> "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." > > For POSIX, this should be stated as a "relative path without a slash in > it" or a "relative path without a

[issue15533] subprocess.Popen(cwd) documentation: Posix vs Windows

Gregory P. Smith added the comment: For our subprocess docs, Eryk's text: """ For POSIX, ``executable`` should be stated as a "relative path without a slash in it" or a "relative path without a directory in it". An unqualified filename is a relative path that won't be resolved against

[issue15533] subprocess.Popen(cwd) documentation: Posix vs Windows

Eryk Sun added the comment: > Python is conceptually multi-platform, so its behavior on > Linux and Windows should be as much consistent as possible. It's not expected for the behavior of all Popen() parameters to be the same on all platforms. For example, the behavior and capabilities of

[issue15533] subprocess.Popen(cwd) documentation: Posix vs Windows

Change by Gregory P. Smith : -- assignee: -> gregory.p.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue15533] subprocess.Popen(cwd) documentation: Posix vs Windows

Change by Chris Jerdonek : -- assignee: chris.jerdonek -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue15533] subprocess.Popen(cwd) documentation: Posix vs Windows

Jan Lachnitt added the comment: Nobody responds yet, so I will. I think that the basic proposal was made by Chris Jerdonek in msg171692 already on 2012-10-01: First document both behaviors and then discuss the possible harmonization. I think the proposal was good and further discussion has

[issue15533] subprocess.Popen(cwd) documentation: Posix vs Windows

Gregory P. Smith added the comment: Thanks for pointing me at this issue Ned. It sounds like there is a behavior difference between Windows and POSIX systems related to the current directory and/or which process environment is used by the system call that launches the new process to find

[issue15533] subprocess.Popen(cwd) documentation: Posix vs Windows

Change by Ned Deily : -- nosy: +gregory.p.smith versions: +Python 3.8 -Python 3.5 ___ Python tracker ___ ___ Python-bugs-list

[issue15533] subprocess.Popen(cwd) documentation: Posix vs Windows

Damon Atkins added the comment: >From https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425.aspx Note Python is using CreateProcess(), consider using CreateProcessW() The Unicode version of this function, CreateProcessW, can modify the contents of this string. Therefore, this

[issue15533] subprocess.Popen(cwd) documentation: Posix vs Windows

Jan Lachnitt added the comment: @eryksun: Sorry for my late reply, apparently I did not have time to reply in 2017. I see your point, but still I think that Python is conceptually multi-platform, so its behavior on Linux and Windows should be as much consistent as possible. I am not the

[issue15533] subprocess.Popen(cwd) documentation: Posix vs Windows

Damon Atkins added the comment: See also https://bugs.python.org/msg262399 -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue15533] subprocess.Popen(cwd) documentation: Posix vs Windows

Damon Atkins added the comment: I see from this. That this is still an issue https://github.com/python/cpython/blob/master/Lib/subprocess.py#L1146 Is it not a solution to save current directory location chdir(cwd) before calling _winapi.CreateProcess() restore the original directory. This

[issue15533] subprocess.Popen(cwd) documentation: Posix vs Windows

Eryk Sun added the comment: The Unix implementation of subprocess.Popen follows the behavior of os.execvpe, which is an outlier. Other execvpe implementations, such as the one added to glibc in 2009, search PATH in the current environment instead of the passed environment. As such, and given

[issue15533] subprocess.Popen(cwd) documentation: Posix vs Windows

Changes by Martin Panter : -- components: +Windows stage: test needed -> needs patch title: subprocess.Popen(cwd) documentation -> subprocess.Popen(cwd) documentation: Posix vs Windows ___ Python tracker

[issue15533] subprocess.Popen(cwd) documentation

Jan Lachnitt added the comment: Thank Wolfgang Maier for reminding this issue and providing various details and observations. Having taken a look at my old comments (and at others' comments, too), I feel that the cwd issue deserves a clearer description. Let's use the following simple C

[issue15533] subprocess.Popen(cwd) documentation

Wolfgang Maier added the comment: Just found issue15451, which reports a similar inconsistency between Windows and POSIX for 'PATH' provided through the Popen env parameter as for cwd. It seems that, on POSIX-platforms, the PATH environment variable passed through env affects the executable

[issue15533] subprocess.Popen(cwd) documentation

Changes by Ned Deily : -- nosy: +paul.moore, steve.dower, tim.golden, zach.ware versions: -Python 3.4 ___ Python tracker ___

[issue15533] subprocess.Popen(cwd) documentation

Wolfgang Maier added the comment: Before I forget again what I've gathered yesterday about this issue, here's a summary of the problem: When the the first element of args or the executable argument of subprocess.Popen does not specify an absolute path, the way the executable gets discovered

[issue15533] subprocess.Popen(cwd) documentation

Wolfgang Maier added the comment: Ping. This still isn't fixed several years later, i.e., the documentation still describes the POSIX, but not the Windows behavior. See also issue20927, which reports this as a bug. -- nosy: +wolma versions: +Python 3.5, Python 3.6, Python 3.7 -Python

[issue15533] subprocess.Popen(cwd) documentation

Ned Deily added the comment: Note, that test_executable_without_cwd now fails when the tests are run from an installed Python. See Issue17046. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15533

[issue15533] subprocess.Popen(cwd) documentation

Jan Lachnitt added the comment: Hi all, I have solved the problem by using absolute path of the executable. The reason why the executable didn't work properly may be that the executable's relative path was inconsistent with current directory. See the following example (I have made an

[issue15533] subprocess.Popen(cwd) documentation

Jan Lachnitt added the comment: Hi, I am using Python 3.2.3 on Windows XP. I encountered a problem with subprocess.call when using the cwd parameter. I used Google to look for a solution and I found this issue in Python tracker. But this issue seems absolutely reversed! The subprocess

[issue15533] subprocess.Popen(cwd) documentation

Chris Jerdonek added the comment: Hi Jan, yes, the documentation now describes the non-Windows behavior, which is different from the Windows behavior. See the comment just before yours on what still needs to be done to resolve this issue. I was in the middle of creating a bunch of test

[issue15533] subprocess.Popen(cwd) documentation

Jan Lachnitt added the comment: EDIT: No, it doesn't work fine: the executable reports stack overflow. I thought this had nothing to do with Python, hence I didn't mention it. But If I run the executable without Python, THEN it works fine. But this may be another issue. I'll update to 3.3.0

[issue15533] subprocess.Popen(cwd) documentation

Jan Lachnitt added the comment: Hi Chris, thank for your reply, I didn't see it while writing the edit. Does it mean that on Linux, it will use the cwd? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15533

[issue15533] subprocess.Popen(cwd) documentation

Roundup Robot added the comment: New changeset abfaa4368263 by Chris Jerdonek in branch '3.2': Issue #15533: Clarify docs and add tests for subprocess.Popen()'s cwd argument. http://hg.python.org/cpython/rev/abfaa4368263 New changeset f66ff96f0030 by Chris Jerdonek in branch '3.3': Issue

[issue15533] subprocess.Popen(cwd) documentation

Chris Jerdonek added the comment: I will commit to 2.7 separately. -- versions: +Python 3.2, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15533 ___

[issue15533] subprocess.Popen(cwd) documentation

Chris Jerdonek added the comment: Two of the tests fail on at least some of the Windows bots. I am investigating. == ERROR: test_cwd_with_relative_arg (test.test_subprocess.ProcessTestCase)

[issue15533] subprocess.Popen(cwd) documentation

Chris Jerdonek added the comment: So it seems the cwd argument to Popen() currently works differently on Windows from Mac OS X. For example, the following doesn't work on Windows (but does on Mac). Windows doesn't look for arg0 relative to arg_cwd: def test_cwd(arg0, arg_cwd):

[issue15533] subprocess.Popen(cwd) documentation

Roundup Robot added the comment: New changeset d8d52b5b4bc2 by Chris Jerdonek in branch '3.2': Issue #15533: Skip test_cwd_with_relative_*() tests on Windows pending resolution of issue. http://hg.python.org/cpython/rev/d8d52b5b4bc2 New changeset 17d709f0b69b by Chris Jerdonek in branch '3.3':

[issue15533] subprocess.Popen(cwd) documentation

Chris Jerdonek added the comment: I propose addressing the remainder of this issue by: 1) Documenting the difference in behavior between Windows and non-Windows, adjusting the tests to reflect this difference, and then closing this issue, and then 2) Creating a new issue to discuss whether

[issue15533] subprocess.Popen(cwd) documentation

Andrew Svetlov added the comment: Chris, please commit your patch. It's fine for me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15533 ___

[issue15533] subprocess.Popen(cwd) documentation

Changes by Chris Jerdonek chris.jerdo...@gmail.com: -- assignee: docs@python - chris.jerdonek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15533 ___

[issue15533] subprocess.Popen(cwd) documentation

Chris Jerdonek added the comment: Andrew, do you think my changes to the patch are adequate given the response on python-dev to your question? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15533

[issue15533] subprocess.Popen(cwd) documentation

Chris Jerdonek added the comment: Here is a proposed patch that attempts to minimize the chance of test breakage for Tru64. The patch follows Martin's recommendation on python-dev of being cautious by following existing code. -- Added file:

[issue15533] subprocess.Popen(cwd) documentation

Andrew Svetlov added the comment: I believe it's trick for Tru64 platform. I've asked to support of this in python-dev. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15533 ___

[issue15533] subprocess.Popen(cwd) documentation

Chris Jerdonek added the comment: For future reference, here is the beginning of the e-mail thread on python-dev: http://mail.python.org/pipermail/python-dev/2012-September/121584.html We also need to know whether the Tru64 trick needs to be used in 2.7, since this documentation issue also

[issue15533] subprocess.Popen(cwd) documentation

Chris Jerdonek added the comment: Andrew, I seem to be getting a test failure for test_executable_with_cwd() with your updated patch (the child process is outputting an absolute path rather than ''). I will update the patch to fix. There are also some stylistic changes I would like to make

[issue15533] subprocess.Popen(cwd) documentation

Chris Jerdonek added the comment: Here is an updated patch. The changes I made are: (1) Update code comments in _call_popen_and_assert(). (2) Fix test failure. (3) Rename _call_popen_and_assert() to _assert_cwd() since it is a simpler name and the old name did not reflect that the method

[issue15533] subprocess.Popen(cwd) documentation

Chris Jerdonek added the comment: Updating the patch again to tweak the original documentation change. I was concerned that the previous language could be construed to mean that Popen will look in *two* places for the executable (both relative to the current directory and relative to the cwd

[issue15533] subprocess.Popen(cwd) documentation

Chris Jerdonek added the comment: Updating the doc portion of the patch one more time. -- Added file: http://bugs.python.org/file27118/issue-15533-7-default.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15533

[issue15533] subprocess.Popen(cwd) documentation

Andrew Svetlov added the comment: Update patch. -- Added file: http://bugs.python.org/file27112/issue-15533-4-default.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15533 ___

[issue15533] subprocess.Popen(cwd) documentation

Chris Jerdonek added the comment: Thanks, Andrew. Regarding your comment, it was a deliberate choice not to do the additional check because I wanted each test to check only one thing. But I am okay with adding the additional check. Regarding the patch, should all of the methods now do

[issue15533] subprocess.Popen(cwd) documentation

Andrew Svetlov added the comment: Maybe better to check cwd in _call_popen_and_assert for child process (like test_cwd does) instead of just checking for successful child execution? -- ___ Python tracker rep...@bugs.python.org

[issue15533] subprocess.Popen(cwd) documentation

Changes by Chris Rebert pyb...@rebertia.com: -- nosy: +cvrebert ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15533 ___ ___ Python-bugs-list

[issue15533] subprocess.Popen(cwd) documentation

Chris Jerdonek added the comment: Attached are a few test cases showing that Popen *does* consider cwd when searching for the executable (as well as for args[0]), and in particular that you *can* specify the program's path relative to cwd. I also moved the test_cwd test to be adjacent to the

[issue15533] subprocess.Popen(cwd) documentation

Changes by Chris Jerdonek chris.jerdo...@gmail.com: -- nosy: +asvetlov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15533 ___ ___

[issue15533] subprocess.Popen(cwd) documentation

Chris Jerdonek added the comment: Here is a full patch for the default branch (documentation correction and test cases for the documented behavior). If this patch looks acceptable, I can prepare a separate patch for 2.7. -- Added file:

[issue15533] subprocess.Popen(cwd) documentation

Changes by Chris Jerdonek chris.jerdo...@gmail.com: -- keywords: +needs review stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15533 ___

[issue15533] subprocess.Popen(cwd) documentation

Chris Jerdonek added the comment: python_dir = os.path.dirname(os.path.realpath(sys.executable)) wrong_cwd = os.path.join(python_dir, 'Doc') Actually, is there a better directory to be using for this? I'd like a directory that is guaranteed to exist that is in the same directory as

[issue15533] subprocess.Popen(cwd) documentation

Ned Deily added the comment: Because tests should be runnable from installed Pythons (including binary -only installations), tests should not assume that a Python source directory is available nor make any assumptions about the location of the Python executable itself. -- nosy:

[issue15533] subprocess.Popen(cwd) documentation

Chris Jerdonek added the comment: Here is a new patch that makes no assumptions about the contents of the directory containing sys.executable. -- Added file: http://bugs.python.org/file27026/issue-15533-3-default.patch ___ Python tracker

[issue15533] subprocess.Popen(cwd) documentation

New submission from Chris Jerdonek: The sentence describing Popen()'s cwd argument in the subprocess documentation seems reversed to me: http://docs.python.org/dev/library/subprocess.html#subprocess.Popen It says, If cwd is not None, the child’s current directory will be changed to cwd