distutils.spawn.find_executable appends '.exe' suffix on win32 and os2
platforms. This is incorrect behavior, since it prevents finding .bat,
.cmd and other similar files. Ether all extensions from the %PATHEXT%
must be checked or filenames both with appended suffix and without
appending suffix must be checked.

Can you provide a patch which uses PATHEXT and falls back to .com, .exe
and .bat?

Here is my vision of this patch. I don't think that it is necessary to
fall back to 'com/exe/bat' if PATHEXT is not set, since it must be set
on any correctly configured Win32 platform.

I can't see this issue on the 'open issues' list nor in the search
results. Is something wrong?

By default issues are sorted by priority. I've given the bug the
priority "normal". Have a look on page 3 or 4.

I've run into the same problem.

Attached patch (updated with Lev code) is almost the same except that it
doesn't attempt to return executable files without executable extension.

It also accounts that os2 executables can have arbitrary extensions
according to Perl manual.
http://www.perl.com/doc/manual/html/Porting/README.os2.html#Starting_OS_2_and_DOS_programs

I think distutils changes should be aimed at several versions, please correct them if I'm wrong.

distutils bugs follow standard Python rules: They are fixed in stable and development branches, now 2.7, 3.1 and py3k.  If there is a security hazard, the fix would go into 2.6 and possibly 2.5 too.

distutils2 has to work with 2.4-2.7 and (soon) 3.1-3.2, so Tarek told me to set all available versions for those bugs (2.5-py3k), even if I think “3rd party” is more appropriate and useful (since a distutils2 bug would not for example block a CPython 3.2 release).

When a bug applies to distutils and distutils2, I prefer to set only versions relevant for distutils.  distutils2 has only one branch which is tested with all supported Python version, and I actually consider distutils2 a version of distutils: It makes more sense to me to think “this bug exists in CPython 3.1, 3.2 and distutils2”.

Could someone provide use cases for this change?  What programs which were not .exe did you need to run though distutils?

My use case was compiling PyQt4 resources and Qt Designer .ui files from setup script using pyrcc4 and pyuic4 commands. On windows pyrcc4 is actually a pyrcc4.bat file (at least it was at the time of the original bug submission - haven't checked current status), and find_exe could not find it.

I believe I had problems with SCons and other .py scripts that are installed as executable .bat files on Windows.

Another use case for .bat files is adddin extra params for executable files.

Thanks for the use cases.  I agree this is a bug, not a feature, so unless Tarek disagrees I will commit the last patch.

I'm not sure this requires tests.

Have the patch been applied ? (the state is still open since last message)

Not yet.

Martin, could you please review patch file11359?

I think the patch is incorrect. Parsing PATHEXT means that it will believe that all extensions listed on PATHEXT are executable. However, os.spawnv is not able to run them all, but only a subset. IIUC, spawnv supports (from spawnve.c)

static _TSCHAR *ext_strings[] = { _T(".cmd"), _T(".bat"), _T(".exe"), _T(".com") };

PATHEXT typically includes also .js and other extensions which cannot be run through spawnv.

Distutils is now deprecated (see PEP 632) and all tagged issues are being closed. From now until removal, only release blocking issues will be considered for distutils.

If this issue does not relate to distutils, please remove the component and reopen it. If you believe it still requires a fix, most likely the issue should be re-reported at https://github.com/pypa/setuptools