 |
 |
 |
 |
 |
 |
Python Library Reference |
|
|
|
|
|
|
Python Library Reference |
These functions may be used to create and manage processes.
The various exec*() functions take a list of arguments for
the new program loaded into the process. In each case, the first of
these arguments is passed to the new program as its own name rather
than as an argument a user may have typed on a command line. For the
C programmer, this is the argv[0] passed to a program's
main(). For example, "os.execv('/bin/echo', ['foo',
'bar'])" will only print "bar" on standard output; "foo"will seem to be ignored.
| ) |
3. Be aware that
programs which use signal.signal() to register a handler
for SIGABRT will behave differently.
Availability: Unix, Windows.
| path, arg0, arg1, ...) |
| path, arg0, arg1, ..., env) |
| file, arg0, arg1, ...) |
| file, arg0, arg1, ..., env) |
| path, args) |
| path, args, env) |
| file, args) |
| file, args, env) |
The "l" and "v" variants of the exec*() functions differ in how command-line arguments are passed. The "l" variants are perhaps the easiest to work with if the number of parameters is fixed when the code is written; the individual parameters simply become additional parameters to the execl*() functions. The "v" variants are good when the number of parameters is variable, with the arguments being passed in a list or tuple as the args parameter. In either case, the arguments to the child process should start with the name of the command being run, but this is not enforced.
The variants which include a "p" near the end (execlp(), execlpe(), execvp(), and execvpe()) will use the PATH environment variable to locate the program file. When the environment is being replaced (using one of the exec*e() variants, discussed in the next paragraph), the new environment is used as the source of the PATH variable. The other variants, execl(), execle(), execv(), and execve(), will not use the PATH variable to locate the executable; path must contain an appropriate absolute or relative path.
For execle(), execlpe(), execve(), and execvpe() (note that these all end in "e"), the env parameter must be a mapping which is used to define the environment variables for the new process; the execl(), execlp(), execv(), and execvp() all cause the new process to inherit the environment of the current process. Availability: Unix, Windows.
| n) |
sys.exit(n).
_exit() should normally only be used in the child process
after a fork().
The following exit codes are a defined, and can be used with _exit(), although they are not required. These are typically used for system programs written in Python, such as a mail server's external command delivery program.
| ) |
0 in the child, the child's
process id in the parent.
Availability: Unix.
| ) |
(pid, fd),
where pid is 0 in the child, the new child's process id
in the parent, and fd is the file descriptor of the master end
of the pseudo-terminal. For a more portable approach, use the
pty module.
Availability: Some flavors of Unix.
| pid, sig) |
| pgid, sig) |
| increment) |
| op) |
<sys/lock.h>) determines which segments are locked.
Availability: Unix.
| ...) |
| ...) |
| ...) |
| ...) |
| mode, path, ...) |
| mode, path, ..., env) |
| mode, file, ...) |
| mode, file, ..., env) |
| mode, path, args) |
| mode, path, args, env) |
| mode, file, args) |
| mode, file, args, env) |
-signal, where
signal is the signal that killed the process. On Windows, the
process ID will actually be the process handle, so can be used with
the waitpid() function.
The "l" and "v" variants of the spawn*() functions differ in how command-line arguments are passed. The "l" variants are perhaps the easiest to work with if the number of parameters is fixed when the code is written; the individual parameters simply become additional parameters to the spawnl*() functions. The "v" variants are good when the number of parameters is variable, with the arguments being passed in a list or tuple as the args parameter. In either case, the arguments to the child process must start with the name of the command being run.
The variants which include a second "p" near the end (spawnlp(), spawnlpe(), spawnvp(), and spawnvpe()) will use the PATH environment variable to locate the program file. When the environment is being replaced (using one of the spawn*e() variants, discussed in the next paragraph), the new environment is used as the source of the PATH variable. The other variants, spawnl(), spawnle(), spawnv(), and spawnve(), will not use the PATH variable to locate the executable; path must contain an appropriate absolute or relative path.
For spawnle(), spawnlpe(), spawnve(), and spawnvpe() (note that these all end in "e"), the env parameter must be a mapping which is used to define the environment variables for the new process; the spawnl(), spawnlp(), spawnv(), and spawnvp() all cause the new process to inherit the environment of the current process.
As an example, the following calls to spawnlp() and spawnvpe() are equivalent:
import os os.spawnlp(os.P_WAIT, 'cp', 'cp', 'index.html', '/dev/null') L = ['cp', 'index.html', '/dev/null'] os.spawnvpe(os.P_WAIT, 'cp', L, os.environ)
Availability: Unix, Windows. spawnlp(), spawnlpe(), spawnvp() and spawnvpe() are not available on Windows. New in version 1.6.
-signal if a signal kills the
process.
Availability: Unix, Windows.
New in version 1.6.
| path) |
startfile() returns as soon as the associated application is launched. There is no option to wait for the application to close, and no way to retrieve the application's exit status. The path parameter is relative to the current directory. If you want to use an absolute path, make sure the first character is not a slash ("/"); the underlying Win32 ShellExecute() function doesn't work if it is. Use the os.path.normpath() function to ensure that the path is properly encoded for Win32. Availability: Windows. New in version 2.0.
| command) |
posix.environ, sys.stdin,
etc. are not reflected in the environment of the executed command.
On Unix, the return value is the exit status of the process encoded in the format specified for wait(). Note that POSIX does not specify the meaning of the return value of the C system() function, so the return value of the Python function is system-dependent.
On Windows, the return value is that returned by the system shell after
running command, given by the Windows environment variable
COMSPEC: on command.com systems (Windows 95, 98 and ME)
this is always 0; on cmd.exe systems (Windows NT, 2000
and XP) this is the exit status of the command run; on systems using
a non-native shell, consult your shell documentation.
Availability: Unix, Windows.
| ) |
| ) |
| pid, options) |
On Unix:
Wait for completion of a child process given by process id pid,
and return a tuple containing its process id and exit status
indication (encoded as for wait()). The semantics of the
call are affected by the value of the integer options, which
should be 0 for normal operation.
If pid is greater than 0, waitpid() requests
status information for that specific process. If pid is
0, the request is for the status of any child in the process
group of the current process. If pid is -1, the request
pertains to any child of the current process. If pid is less
than -1, status is requested for any process in the process
group -pid (the absolute value of pid).
On Windows:
Wait for completion of a process given by process handle pid,
and return a tuple containing pid,
and its exit status shifted left by 8 bits (shifting makes cross-platform
use of the function easier).
A pid less than or equal to 0 has no special meaning on
Windows, and raises an exception.
The value of integer options has no effect.
pid can refer to any process whose id is known, not necessarily a
child process.
The spawn() functions called with P_NOWAIT
return suitable process handles.
The following functions take a process status code as returned by system(), wait(), or waitpid() as a parameter. They may be used to determine the disposition of a process.
| status) |
True if a core dump was generated for the process,
otherwise it returns False.
Availability: Unix.
New in version 2.3.
| status) |
True if the process has been continued from a job
control stop, otherwise it returns False.
Availability: Unix.
New in version 2.3.
| status) |
True if the process has been stopped, otherwise it
returns False.
Availability: Unix.
| status) |
True if the process exited due to a signal, otherwise
it returns False.
Availability: Unix.
| status) |
True if the process exited using the exit(2)
system call, otherwise it returns False.
Availability: Unix.
| status) |
WIFEXITED(status) is true, return the integer
parameter to the exit(2) system call. Otherwise, the return
value is meaningless.
Availability: Unix.
| status) |
| status) |
|
|
|
|
|
|
Python Library Reference |