[issue24505] shutil.which wrong result on Windows

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24505] shutil.which wrong result on Windows

Eryk Sun added the comment: Regarding Toby's patch: Probably _is_windows_nt_internal_command() isn't needed or desired. It's more of a command-line parsing issue, rather than a file-search issue. For example, CMD will search for an internal name if it's quoted in double quotes in the

[issue24505] shutil.which wrong result on Windows

Change by Роман Донченко : -- nosy: +SpecLad ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24505] shutil.which wrong result on Windows

STINNER Victor added the comment: This issue is not newcomer friendly, I remove the easy keyword. -- keywords: -easy nosy: +vstinner ___ Python tracker ___

[issue24505] shutil.which wrong result on Windows

Bob Alexander added the comment: Oops, clarification... I just reread my kind of long previous post, and realized it wasn't very explicit that anything concerning file extensions or prepending the current directory to the PATH apply to Windows only; not Unix (of course). The "returning

[issue24505] shutil.which wrong result on Windows

Bob Alexander added the comment: Since there seems to be ongoing work on the "which" function, here are a few more thoughts on this function's future: - The existing version does not prepend the current directory to the path if it is already in the path. If the current directory is in

[issue24505] shutil.which wrong result on Windows

Toby Tobkin added the comment: Steve, yeah I saw that and started playing with Clinic last night. I'll have the updated patch out soon--I've just been slow because I've been flying around to interviews trying to get my first job out of college and it's been eating all my free time.

[issue24505] shutil.which wrong result on Windows

Steve Dower added the comment: I'm good with the patch, except we can't use ctypes in the standard library. NeedCurrentDirectoryForExePathW will need to be wrapped in Modules/_winapi.c. Should be fairly simple to do, though it probably requires learning argument clinic (which admittedly I

[issue24505] shutil.which wrong result on Windows

Toby Tobkin added the comment: Patch incorporating Eryk Sun's feedback for various Windows-specific behavior attached. -- Added file: http://bugs.python.org/file41459/issue-24505-proposed-patch-2.diff ___ Python tracker

[issue24505] shutil.which wrong result on Windows

Toby Tobkin added the comment: Patch and tests attached. All Python tests passed on Windows 8 and Ubuntu 14.04LTS. -- keywords: +patch Added file: http://bugs.python.org/file41338/issue 24505 proposed patch windows cmd semantics.patch ___ Python

[issue24505] shutil.which wrong result on Windows

Toby Tobkin added the comment: Hopefully this isn't too much of an amateur question, but I ran into a semantics issue: should which be imitating the semantics of the Windows shell or of CreateProcess[3]? The current implementation of shutil.which implies Windows shell, but Python uses

[issue24505] shutil.which wrong result on Windows

Toby Tobkin added the comment: I'm working on a patch and an accompanying unit test for this now. Should have it out today. -- nosy: +tobytobkin ___ Python tracker

[issue24505] shutil.which wrong result on Windows

R. David Murray added the comment: Well, that's a newish situation for Windows, something I certainly wasn't aware of. Which is trying to find the executable that would be found if typed at the prompt. So, what is the correct algorithm for emulating how Windows does that search? (Or some

[issue24505] shutil.which wrong result on Windows

Steve Dower added the comment: The Win32 API function linked by eryksun is the correct way to determine whether to include the current directory in the search - the doc specifically refers to matching cmd.exe's behaviour (searching ".;%PATH%" vs. just "%PATH%"). The PATHEXT behaviour should

[issue24505] shutil.which wrong result on Windows

eryksun added the comment: My suggestion is only for 3.5 / 3.6, because Windows XP is no longer supported. Starting with Windows Vista, both cmd.exe and CreateProcess support this behavior. I realize that disabling searching the current director by default is going beyond what cmd.exe does,

[issue24505] shutil.which wrong result on Windows

Bar Harel added the comment: Unfortunately that patch will not help for files like "python.exe.exe", and double ext which sometimes happens. I'm on it. Should take me a day or two, more problems might arise along the way. Thanks Bob for alerting. Regarding the uppercase, I believe it is

[issue24505] shutil.which wrong result on Windows

eryksun added the comment: Please don't default to searching the current directory: if is_windows: # The current directory takes precedence on Windows. if not os.curdir in path: path.insert(0, os.curdir) Add a keyword option to enable this, with a warning that

[issue24505] shutil.which wrong result on Windows

Bob Alexander added the comment: Hi R. David -- My report is just to notify y'all of a bug that I noticed. The bug is causing me no problem, and it's your option as to whether to fix it or not. I offered a fix, but I haven't the time to perform diffs, etc. You could make that diff yourself,

[issue24505] shutil.which wrong result on Windows

R. David Murray added the comment: That's fine. Perhaps someone will be interested enough to pick this up and work on it. -- keywords: +easy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24505

[issue24505] shutil.which wrong result on Windows

New submission from Bob Alexander: Python session with 3.5b2 Showing existing error: from shutil import which Works OK which(python) 'C:\\Python27\\python.EXE' Also works OK which('C:\\Python27\\python.EXE') 'C:\\Python27\\python.EXE' Fails which('C:\\Python27\\python') Showing better

[issue24505] shutil.which wrong result on Windows

R. David Murray added the comment: Could you please submit your proposal as a patch? (A diff -u against the existing version). -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24505