Executes a child program asynchronously (your program will not block waiting for the child to exit).
The child program is specified by the only argument that must be provided, argv. argv should be a
null-terminated array of strings, to be passed as the argument vector for the child. The
first string in argv is of course the name of the program to execute. By default, the name of the program must be a full
path. If flags contains the g_spawn_search_path flag, the `PATH` environment
variable is used to search for the executable. If flags contains the
g_spawn_search_path_from_envp flag, the `PATH` variable from envp is used to search for the executable. If both the
g_spawn_search_path and g_spawn_search_path_from_envp
flags are set, the `PATH` variable from envp takes precedence over the environment variable.
If the program name is not a full path and g_spawn_search_path flag is not used, then the
program will be run from the current directory (or working_directory, if specified); this might be unexpected or even
dangerous in some cases when the current directory is world-writable.
On Windows, note that all the string or string vector arguments to this function and the other g_spawn*() functions are in UTF-8, the
GLib file name encoding. Unicode characters that are not part of the system codepage passed in these arguments will be correctly available
in the spawned program only if it uses wide character API to retrieve its command line. For C programs built with Microsoft's tools it is
enough to make the program have a wmain instead of main. wmain has a wide character argument
vector as parameter.
At least currently, mingw doesn't support wmain, so if you use mingw to develop the spawned program, it will have to call
the undocumented function __wgetmainargs to get the wide character argument vector and environment. See gspawn-win32-helper.c
in the GLib sources or init.c in the mingw runtime sources for a prototype for that function. Alternatively, you can retrieve the Win32
system level wide character command line passed to the spawned program using the GetCommandLineW function.
On Windows the low-level child process creation API CreateProcess doesn't use argument vectors, but a command line. The C
runtime library's spawn*() family of functions (which spawn_async_with_pipes eventually calls) paste the
argument vector elements together into a command line, and the C runtime startup code does a corresponding reconstruction of an argument
vector from the command line, to be passed to main. Complications arise when you have argument vector elements that contain
spaces of double quotes. The spawn*() functions don't do any quoting or escaping, but on the other hand the startup code does do unquoting
and unescaping in order to enable receiving arguments with embedded spaces or double quotes. To work around this asymmetry,
spawn_async_with_pipes will do quoting and escaping on argument vector elements that need it before calling
the C runtime spawn function.
The returned child_pid on Windows is a handle to the child process, not its identifier. Process handles and process
identifiers are different concepts on Windows.
envp is a null-terminated array of strings, where each string has the form
`KEY=VALUE`. This will become the child's environment. If envp is null, the
child inherits its parent's environment.
flags should be the bitwise OR of any flags you want to affect the function's behaviour. The
g_spawn_do_not_reap_child means that the child will not automatically be reaped; you must use
a child watch to be notified about the death of the child process. Eventually you must call
close_pid on the child_pid, in order to free resources which may be
associated with the child process. (On Unix, using a child watch is equivalent to calling waitpid or handling the
sigchld signal manually. On Windows, calling
close_pid is equivalent to calling CloseHandle on the process handle
returned in child_pid). See g_child_watch_add.
g_spawn_leave_descriptors_open means that the parent's open file descriptors will be
inherited by the child; otherwise all descriptors except stdin/stdout/stderr will be closed before calling exec in the child.
g_spawn_search_path means that argv[0] need not be an absolute path, it will be
looked for in the `PATH` environment variable. g_spawn_search_path_from_envp means need not
be an absolute path, it will be looked for in the `PATH` variable from envp. If both
g_spawn_search_path and g_spawn_search_path_from_envp are used, the value from
envp takes precedence over the environment. g_spawn_stdout_to_dev_null means
that the child's standard output will be discarded, instead of going to the same location as the parent's standard output. If you use this
flag, standard_output must be null.
g_spawn_stderr_to_dev_null means that the child's standard error will be discarded, instead of going to the same location as the
parent's standard error. If you use this flag, standard_error must be null.
g_spawn_child_inherits_stdin means that the child will inherit the parent's standard input (
by default, the child's standard input is attached to /dev/null). If you use this flag, standard_input must be
null. g_spawn_file_and_argv_zero means that the
first element of argv is the file to execute, while the remaining elements are the actual argument vector to pass to the
file. Normally spawn_async_with_pipes uses argv[0] as the file to execute, and passes all of
argv to the child.
child_setup and user_data are a function and user data. On POSIX platforms, the function is called in the child
after GLib has performed all the setup it plans to perform (including creating pipes, closing file descriptors, etc.) but before calling
exec. That is, child_setup is called just before calling exec in the child. Obviously actions taken
in this function will only affect the child, not the parent.
On Windows, there is no separate fork and exec functionality. Child processes are created and run with a single
API call, CreateProcess. There is no sensible thing child_setup could be used for on Windows so it is ignored
and not called.
If non-null, child_pid will on Unix be filled with the child's process ID. You
can use the process ID to send signals to the child, or to use g_child_watch_add (or waitpid) if you specified
the g_spawn_do_not_reap_child flag. On Windows, child_pid will be filled with a
handle to the child process only if you specified the g_spawn_do_not_reap_child flag. You can
then access the child process using the Win32 API, for example wait for its termination with the WaitFor*() functions, or examine its
exit code with GetExitCodeProcess. You should close the handle with CloseHandle or
close_pid when you no longer need it.
If non-null, the standard_input, standard_output,
standard_error locations will be filled with file descriptors for writing to the child's standard input or reading from its
standard output or standard error. The caller of spawn_async_with_pipes must close these file descriptors when
they are no longer in use. If these parameters are null, the corresponding pipe won't be
created.
If standard_input is NULL, the child's standard input is attached to /dev/null unless
g_spawn_child_inherits_stdin is set.
If standard_error is NULL, the child's standard error goes to the same location as the parent's standard error unless
g_spawn_stderr_to_dev_null is set.
If standard_output is NULL, the child's standard output goes to the same location as the parent's standard output unless
g_spawn_stdout_to_dev_null is set.
throws can be null to ignore errors, or non-
null to report errors. If an error is set, the function returns
false. Errors are reported even if they occur in the child (for example if the executable in
argv[0] is not found). Typically the `message` field of returned errors should be displayed to users. Possible errors are
those from the SpawnError domain.
If an error occurs, child_pid, standard_input, standard_output, and standard_error
will not be filled with valid values.
If child_pid is not null and an error does not occur then the returned process
reference must be closed using close_pid.
If you are writing a GTK+ application, and the program you are spawning is a graphical application, too, then you may want to use
gdk_spawn_on_screen_with_pipes instead to ensure that the spawned program opens its windows on the right screen.
| working_directory |
child's current working directory, or null to inherit parent's, in the GLib file name encoding |
| argv |
child's argument vector, in the GLib file name encoding |
| envp |
child's environment, or null to inherit parent's, in the GLib file name encoding |
| child_setup |
function to run in the child just before |
| child_pid |
return location for child process ID, or null |
| standard_input |
return location for file descriptor to write to child's stdin, or null |
| standard_output |
return location for file descriptor to read child's stdout, or null |
| standard_error |
return location for file descriptor to read child's stderr, or null |
| flags |
flags from SpawnFlags |
| user_data |
user data for |
|
true on success, false if an error was set |