-
-
Notifications
You must be signed in to change notification settings - Fork 30.1k
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
[doc] os.execvp[e] on win32 fails for current directory #44123
Comments
By convention when program is executed by searching 1.c:
int main() { return 1; } test.py: 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 What convention are you referring to? By convention, you |
Logged In: YES On win32 it is not so, execlp() in msvcrt, for example, will |
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 |
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. |
Co-authored-by: Steve Dower <[email protected]>
Closing this issue, #93826 has been merged that updated the docs. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
Linked PRs
The text was updated successfully, but these errors were encountered: