[issue8557] subprocess PATH semantics and portability

Change by Henry Schreiner : -- nosy: +Henry Schreiner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://

[issue8557] subprocess PATH semantics and portability

Eryk Sun added the comment: The Popen() docs begin by explaining that it has "os.execvp()-like" behavior in POSIX and uses CreateProcess() in Windows. Personally, I do not think it's proper for Python's documentation to discuss details of how CreateProcess() handles lpCommandLine (args), lp

[issue8557] subprocess PATH semantics and portability

Jan Lachnitt added the comment: A related issue exists with cwd: #15533. -- nosy: +pepalogik ___ Python tracker ___ ___ Python-bugs-

[issue8557] subprocess PATH semantics and portability

Changes by Eryk Sun : -- versions: +Python 3.5, Python 3.6, Python 3.7 -Python 2.6, Python 3.1, Python 3.2 ___ Python tracker ___ ___

[issue8557] subprocess PATH semantics and portability

Eryk Sun added the comment: As is documented for CreateProcess [1], the search path always includes the following directories: * The directory from which the application loaded. * The current directory for the parent process. * The Windows system directory. Use the GetSystemDi

[issue8557] subprocess PATH semantics and portability

Anthony Sottile added the comment: Here's the workaround I'm opting for: if sys.platform =='win32': distutils.spawn.find_executable(cmd[0]) + cmd[1:] -- nosy: +Anthony Sottile ___ Python tracker ___

[issue8557] subprocess PATH semantics and portability

Changes by Reuben Garrett : -- nosy: +RubyTuesdayDONO ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue8557] subprocess PATH semantics and portability

Dave Abrahams added the comment: New data point: in some contexts on Windows (not sure of the exact cause but I was dealing with multiple drives), even this workaround isn't enough. I ended up having to do something like this (i.e. manually search the path) on win32: def full_executable

[issue8557] subprocess PATH semantics and portability

R. David Murray added the comment: Fair enough. Thank you for your detective work, and hopefully someone will be interested enough to pick this up again later. -- status: open -> languishing ___ Python tracker __

[issue8557] subprocess PATH semantics and portability

Dave Abrahams added the comment: R. David Murray wrote: > There are two questions here: (1) is this behavior consistent across all > microsoft platforms we support? I'll be honest: I don't know. > (2) is this *change* in behavior of Popen acceptable? I don't know that either. > I'll be mo

[issue8557] subprocess PATH semantics and portability

R. David Murray added the comment: Well, it wouldn't be the first time the microsoft docs were wrong. There are two questions here: (1) is this behavior consistent across all microsoft platforms we support? (2) is this *change* in behavior of Popen acceptable? For (1) we need a unit test ad

[issue8557] subprocess PATH semantics and portability

Dave Abrahams added the comment: I'm probably as ignorant as you are of Windows issues. I just know what my experiments tell me: if you force the contents of any explicit 'env' argument into os.environ before calling Popen, you get the same behavior as on *nix. -- ___

[issue8557] subprocess PATH semantics and portability

R. David Murray added the comment: Sorry for my Windows ignorance, but if CreateProcess ignores the PATH, how does updating the PATH fix the problem? -- ___ Python tracker ___ _

[issue8557] subprocess PATH semantics and portability

Dave Abrahams added the comment: Not to appear impatient, but It's a fairly tidy answer, I think :-) -- ___ Python tracker ___ ___

[issue8557] subprocess PATH semantics and portability

Changes by Dave Abrahams : Removed file: http://bugs.python.org/file17142/probe.py ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue8557] subprocess PATH semantics and portability

Dave Abrahams added the comment: I've uploaded a new probe.py that contains a win32 Popen wrapper that I think acts just like *nix's Popen w.r.t. PATH and environment (pass --fix to demonstrate). I suggest using this or an equivalent wrapper for Win32, and documenting the fact that with shel

[issue8557] subprocess PATH semantics and portability

R. David Murray added the comment: I didn't run the script. I have now, but I'm not clear from its output what each test is actually doing, and don't really have the time to figure it out from the code right now. I think it is probably more efficient to just ask you what your suggestion is

[issue8557] subprocess PATH semantics and portability

Dave Abrahams added the comment: @r.david.murray: did you try running my test? I think it shows that we are pretty darned close to fully portable. I believe we could fix Popen to make it fully portable pretty easily. In fact, there may be a pure-python fix. Documenting the differences wou

[issue8557] subprocess PATH semantics and portability

Brian Curtin added the comment: You could take the "(VS8.5)" part out of the link which will give the latest version, which may not always be the relevant version (although I doubt this specific API would change). That's about the best permalink-like feature you'll find, but overall, leaving

[issue8557] subprocess PATH semantics and portability

R. David Murray added the comment: Well, it seems I was mistaken when I thought I knew how this worked :) Checking the os.exec documentation linked from the subprocess page, I see that when an environment is supplied PATH is indeed checked in it. The documentation for CreateProcess, however,

[issue8557] subprocess PATH semantics

Dave Abrahams added the comment: I wrote a Python script (enclosed) to methodically test how these things work, that doesn't rely on peculiarities of sys.executable. The tests did reveal some notable differences on *nix and 'doze: * When shell=False on windows you must launch the process usi

[issue8557] subprocess PATH semantics

R. David Murray added the comment: Changing the default value of shell is not an option anyway. The behavior you describe is exactly what one should expect: the environment in which the executable is located is the environment of the process calling Popen, not the environment passed to Popen.