Am 09.02.17 um 18:16 schrieb Andreas Paeffgen: > I guess which does not return an error code.
In fact, id does return a return code. Here an example: | honk:~ gdie$ which bash; echo $? | /bin/bash | 0 | honk:~ gdie$ which wzlbrmpf; echo $? | 1 It is 0 on success, 1 for a failure. Exactly the result I would expect from an unixoid program. On Ubuntu 16.04, 'man which' tells of three possible exit states: 0, 1 and 2. On Mac OS, the return codes are not documented. It seems, there are only 0 (success) and 1 (failure). Normally, on unixoid operating systems, return code 0 indicates success, anything else non-success, failure or error. > If it does not find > anything, the return is just blank. If it finds something, the path is > returned. That is the result on STDOUT. It is _not_ the return code! > So the change of code did not help, because there is just no error message. Do you expect an error message, or a return code? An error message would -- normally -- appear on STDERR. > Could there be a $path problem in the subprocess started inside the binary? That's for sure. I already had this problem with py2exe. I solved it by passing a directory containing a suitable PATH entry to the env argument of subprocess.Popen(). Problem gone. If you call 'python myscript.py' on the shell command line, the python script will inherit a copy the shell's environment. If you start a frozen python script, there is no shell's environment, it could inherit. It is up to the tool you used to freeze the script (cx_freeze, py2exe, etc.), which environment contents it will see. Best regards, Günther -- https://mail.python.org/mailman/listinfo/python-list