Suggestion to document sublte difference between os.execlp, os.execlpe vs native library
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
participants (1)
-
Hlavina, Wratko (NIH/NLM/NCBI) [C]