A subtle issue of a missing shebang in an executable script revealed how Python’s platform-independent versions of os.execlp, os.execlpe deviate from the native operating system implementation (in my case, Linux CentOS and SuSE). Googling during a debug session didn’t provide an obvious answer to the issue (observed in a call to subproces.Popen), and this caused a little head-scratching before figuring out the cause.

 

I have no objection to the difference in behavior (in fact, I believe the Python behavior is safer!), but I do believe a clear warning in the documentation for os.execlp and os.execlpe is in order, stating that they do not necessarily behave the same way as the underlying OS implementation, and that, in particular, header processing (shebang #! lines) is different: presumably, the executable “must  be either a binary executable, or a script starting with a line of the form "#! interpreter [arg]".

 

This comes from forwarding the family of os.exec* functions to os._execvpe, which itself forwards to posix.execve or posix.execv, instead of the underlying operating system versions of execlp and execvp (neither of which are available from the posix module).

 

Thank you and kind regards,

 

 

$ man execve

 

[…]

       filename  must  be either a binary executable, or a script

       starting with a line of the form "#!  interpreter  [arg]".

[…]

 

$ man execlp

 

[…]

 

       Some of these functions have special semantics.

 

       The functions execlp and execvp will duplicate the actions

       of  the  shell  in searching for an executable file if the

       specified file name does not contain a slash  (/)  charac­

       ter.   The  search path is the path specified in the envi­

       ronment by the PATH  variable.   If  this  variable  isn't

       specified,  the  default  path ``:/bin:/usr/bin'' is used.

       In addition, certain errors are treated specially.

 

       If permission is denied for a file (the  attempted  execve

       returned  EACCES), these functions will continue searching

       the rest of the search path.  If no other file  is  found,

       however,  they  will return with the global variable errno

       set to EACCES.

 

       If the header of a file isn't  recognized  (the  attempted

       execve returned ENOEXEC), these functions will execute the

       shell with the path of the file  as  its  first  argument.

       (If this attempt fails, no further searching is done.)

 

--
Wratko HLAVINA
Office NCBI Building 45 Floor 4 Room AS13D-121
       301-402-9730 voice, 301-480-2484 fax
Urgent? cc:urgent@hlavina.com