classification
Title: os.execvp[e] on win32 fails for current directory
Type: behavior Stage: needs patch
Components: Documentation Versions: Python 3.1, Python 3.2, Python 2.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: docs@python Nosy List: docs@python, loewis, mcmahon_m, r.david.murray, snaury, techtonik
Priority: normal Keywords: patch

Created on 2006-10-13 00:57 by snaury, last changed 2019-03-15 23:31 by BreamoreBoy.

Files
File name Uploaded Description Edit
python-win32-execvp.patch snaury, 2006-10-13 00:57 review
Issue1576313.diff BreamoreBoy, 2014-06-19 14:09 Add one sentence to os.rst review
Messages (11)
msg51239 - (view) Author: Alexey Borzenkov (snaury) Date: 2006-10-13 00:57
By convention when program is executed by searching
path, the first directory to be searched should be the
current directory. However on python this is not true:

1.c:
  int main() { return 1; }

test.py:
  import os
  os.execvp('1', ('1',))

result:
  Traceback (most recent call last):
    File "C:\1\test.py", line 2, in <module>
      os.execvp('1',('1',))
    File "D:\Programs\ActiveState\Python25\lib\os.py",
line 348, in execvp
      _execvpe(file, args)
    File "D:\Programs\ActiveState\Python25\lib\os.py",
line 386, in _execvpe
      func(fullname, *argrest)
  OSError: [Errno 2] No such file or directory

Attached patch fixes this.
msg51240 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2006-10-14 19:51
Logged In: YES 
user_id=21627

What convention are you referring to? By convention, you
have to specify executables in the current directory with
./<program> if you don't have "." in your path.
msg51241 - (view) Author: Alexey Borzenkov (snaury) Date: 2006-10-14 20:15
Logged In: YES 
user_id=1197042

On win32 it is not so, execlp() in msvcrt, for example, will
always looks in current directory before looking on PATH
(and if I remember correctly OS/2 has the same rules, I
don't remember PATH on OS/2 ever needing . in the PATH), so
does CreateFile, so on win32 it's just what is expected.
Sorry if I'm wrong though...
msg51242 - (view) Author: Mark Mc Mahon (mcmahon_m) Date: 2007-03-07 18:55
I don't know about OS/2 but standard windows definitely looks in the current folder first.

Should the patch insert "." rather then ""? 

>>> import os.path
>>> os.path.join("", "test")
'test'
>>> os.path.join(".", "test")
'.\\test'
>>>


msg51243 - (view) Author: Alexey Borzenkov (snaury) Date: 2007-03-07 19:15
No, inserting '.' is unnecessary exactly because ntpath.join is working the way you described. On Windows and OS/2 'test' will mean 'test' in current directory, i.e. the expected result without any unnecessary characters prepended and without any unnecessary cycles since ntpath.join("", "whatever") is optimized in ntpath.join.
msg51244 - (view) Author: Mark Mc Mahon (mcmahon_m) Date: 2007-03-07 19:38
Yes of course! I had slightly misunderstood the original problem. I had thought it was execv/execve that had to have the full path, but I see that it is actually os._execvpe() that is only looking in explicit path entry locations for the file (and we need to add the implicit by allowing `file` to be found).
msg109177 - (view) Author: anatoly techtonik (techtonik) Date: 2010-07-03 11:49
There should be one uniform behavior on all platforms if Python is crossplatoform.

As far as I can understand this issue - unix os.execv() requires "./" to be present to execute anything from current directory. On windows it is enough to specify just filename, but os.execv() doesn't work in this way - is that right and the issue is to make behavior of os.execv() like on windows?

The current behavior definitely needs to be documented.
msg109184 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-07-03 15:08
The unix model should be followed (requiring an explicit reference to the current directory if it is not already in PATH), rather than the insecure Windows behavior, and this is indeed the current situation.  The current behavior is documented ("a full or relative path"), but a footnote that this differs from the msvcrt behavior would probably be a useful addition.  So I'm changing this to a doc bug.  (I have verified that ./ works, I have not verified the msvcrt behavior.)
msg220948 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-06-18 19:48
I'd intended to write a patch but got confused as msg51241 talks about "execlp() in msvcrt" but execlp is in the os module.  Please advise.
msg220952 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-06-18 20:14
os.execlp *wraps* the interface of the same name in the platform C library.  On Windows, that is execlp in the msvcrt[*].  On Linux, it is usually the execlp in glibc.

[*] 'crt' stands for 'C runtime'.
msg220980 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-06-19 14:09
The patch deliberately says Windows msvcrt to distinguish it from the Python module of the same name.
History
Date User Action Args
2019-03-15 23:31:42BreamoreBoysetnosy: - BreamoreBoy
2014-06-19 14:09:58BreamoreBoysetfiles: + Issue1576313.diff

messages: + msg220980
2014-06-18 20:14:11r.david.murraysetmessages: + msg220952
2014-06-18 19:48:29BreamoreBoysetnosy: + BreamoreBoy
messages: + msg220948
2010-07-03 15:08:28r.david.murraysetassignee: docs@python
type: enhancement -> behavior
components: + Documentation, - Windows
versions: + Python 3.1
nosy: + r.david.murray

messages: + msg109184
stage: test needed -> needs patch
2010-07-03 11:49:24techtoniksetnosy: + docs@python, techtonik

messages: + msg109177
versions: + Python 3.2
2009-03-30 07:20:47ajaksu2setstage: test needed
type: enhancement
versions: + Python 2.7, - Python 2.5
2006-10-13 00:57:39snaurycreate