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.

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.

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...

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'
>>>

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.

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).

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.

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.)

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.

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'.

The patch deliberately says Windows msvcrt to distinguish it from the Python module of the same name.