Why must path be in args in os.execv?
Jeff Epler
jepler at inetnebr.com
Thu Jul 1 11:26:52 EDT 1999
More information about the Python-list mailing list
Thu Jul 1 11:26:52 EDT 1999
- Previous message (by thread): Why must path be in args in os.execv?
- Next message (by thread): Why must path be in args in os.execv?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Holger, On Unix, read the manpage for execve and friends. You will see that the first argument is the path to the executable, and the subsequent arguments describe the arguments (including argv[0]) and optionally the environment. By convention, argv[0] is the basename of the executable when the executable is on the PATH, and the full path otherwise. (Another unix convention is that when the first letter of argv[0] is "-", the shell is a login shell) DOS doesn't really have execve. It's possible that the imitation is less perfect than it could be. Instead, it may do the equivalent of entering the string string.join(argv, " ") in the shell, i.e., ignoring the path argument. This looks like a shortcoming in the DOS (windows 9x, NT) implementation of exec*, in a way that makes it work differently from the Unix it attempts to imitate. This wouldn't surprise me, since I recently discovered that NT's spawnl takes a unix-like array of arguments (const char *argv[]) but when any element contains a space, it is split into two arguments in the child process. So, I had to break some code that had worked fine on Unix to generate argv, by quoting each argument (something that would *not* work on Unix) .. Bad enough that Windows wants to copy Unix, they have to consistently get it subtly wrong too. Jeff
- Previous message (by thread): Why must path be in args in os.execv?
- Next message (by thread): Why must path be in args in os.execv?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list