homepage

Hello,
I am the author of the Python compiler Nuitka. It has the ability to immediately execute the created executable file. For that I am using "os.execl" to immediately replace the compiler and run the freshly created binary instead.
This worked well so far, but as of late, I am also checking the exit codes, and it turns out that even for failing programs, the exit code is "0" on Windows, even though the compiled binary is exiting with "1".
Investigating further, I made a simple program:
-------
import os
os.execl( "FailingProgram.exe", "lala" )
-------
And it turns out, it's giving me "0", whereas when executed directly "FailingProgram.exe" gives "1". Checking %errorlevel% manually that is, my test framework uses "subprocess" module and gets "0".
The same code works fine (preserves exit code) under Linux. I didn't find the windows specific code responsible for implementing "os.execv" under Win32. I am suspecting that somehow "cmd.exe" may not be propagating the error code, but for that to confirm I would need pointers.
Thanks in advance,
Kay

Python's os.execl simply calls Windows' execv() function, which AFAIK has nothing to do with cmd.exe.

Well, I saw that code, but expected that there must be more to it. But I found out, the bug is actually caused by at least MinGW. See below how I build a program with it, that does "execl" on an error exiting program and then the "errorlevel" variable is "0", whereas direct execution gives "1".
I don't have MSVC installed, so I cannot tell if it is affected as well. I will report this as a bug to MinGW then.
c:\Users\hayen\Nuitka>gcc -v
Es werden eingebaute Spezifikationen verwendet.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw/lib/../libexec/gcc/mingw32/4.6.2/lto-wrapper.exe
Ziel: mingw32
Konfiguriert mit: ../gcc-4.6.2/configure --enable-languages=c,c++,ada,fortran,ob
jc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libg
omp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-
runtime-libs --build=mingw32 --prefix=/mingw
Thread-Modell: win32
gcc-Version 4.6.2 (GCC)
c:\Users\hayen\Nuitka>gcc exec_sample.cpp
c:\Users\hayen\Nuitka>type exec_sample.cpp
#include <unistd.h>
#include <stdio.h>
int main()
{
 puts( "Hello bad world!" );
 execl( "badprogram.exe", "badprogram", "what" );
 puts( "Look, this is not happening!" );
 return 2;
}
c:\Users\hayen\Nuitka>.\a.exe
Hello bad world!
c:\Users\hayen\Nuitka>Traceback (most recent call last):
 File "tests\syntax\RelativeNonPackageImport.py", line 20, in <module>
 from . import whatever
ValueError: Attempted relative import in non-package
c:\Users\hayen\Nuitka>echo %errorlevel%
0
c:\Users\hayen\Nuitka>.\badprogram.exe
Traceback (most recent call last):
 File "tests\syntax\RelativeNonPackageImport.py", line 20, in <module>
 from . import whatever
ValueError: Attempted relative import in non-package
c:\Users\hayen\Nuitka>echo %errorlevel%
1

immediately execute the created executable file. For that I am using
"os.execl" to immediately replace the compiler and run the freshly created
binary instead.
>
> This worked well so far, but as of late, I am also checking the exit
codes, and it turns out that even for failing programs, the exit code is
"0" on Windows, even though the compiled binary is exiting with "1".
This is expected behavior on Windows: exec does not replace the existing
process like with Unix, it creates a new process and exit(0) the caller.

Does the Python standard library not offer anything that does replace with current process code with another? I checked with subprocess, and admittedly it's not that. Does Win32 API offer nothing for that?

No. On Windows the only way to start a new executable is to create a new process (with the CreateProcess function, which all spawn* and exec* functions ultimately call), and this yields a new PID.
This is a fundamental difference with unix, where the only way to create a process is to clone the current one with fork().
And yes, this makes launchers more difficult to write on Windows. For a discussion see the paragraph "Process Launching" in http://www.python.org/dev/peps/pep-0397/ 

Closing as it's been pending for six months and I see nothing further to add