## Spawning Processes Spawning Processes — process launching |

## Functions

void | (*GSpawnChildSetupFunc) ()
gboolean | g_spawn_async_with_pipes ()
gboolean | g_spawn_async ()
gboolean | g_spawn_sync ()
gboolean | g_spawn_check_exit_status ()
gboolean | g_spawn_command_line_async ()
gboolean | g_spawn_command_line_sync ()
void | g_spawn_close_pid ()

## Types and Values

enum | GSpawnError
#define | G_SPAWN_ERROR
enum | GSpawnFlags
#define | G_SPAWN_EXIT_ERROR

## Includes

    #include <glib.h>

## Description

GLib supports spawning of processes with an API that is more convenient than the bare UNIX `fork()` and `exec()`.

The g_spawn family of functions has synchronous (`g_spawn_sync()`) and asynchronous variants (`g_spawn_async()`, `g_spawn_async_with_pipes()`), as well as convenience variants that take a complete shell-like commandline (`g_spawn_command_line_sync()`, `g_spawn_command_line_async()`).

See GSubprocess in GIO for a higher-level API that provides stream interfaces for communication with child processes.

## Functions

### GSpawnChildSetupFunc ()

    void
    (*GSpawnChildSetupFunc) (gpointer user_data);

Specifies the type of the setup function passed to `g_spawn_async()`, `g_spawn_sync()` and `g_spawn_async_with_pipes()`, which can, in very limited ways, be used to affect the child's execution.

On POSIX platforms, the function is called in the child after GLib has performed all the setup it plans to perform, but before calling `exec()`. Actions taken in this function will only affect the child, not the parent.

On Windows, the function is called in the parent. Its usefulness on Windows is thus questionable. In many cases executing the child setup function in the parent can have ill effects, and you should be very careful when porting software to Windows that uses child setup functions.

However, even on POSIX, you are extremely limited in what you can safely do from a GSpawnChildSetupFunc, because any mutexes that were held by other threads in the parent process at the time of the `fork()` will still be locked in the child process, and they will never be unlocked (since the threads that held them don't exist in the child). POSIX allows only async-signal-safe functions (see signal(7)) to be called in the child between `fork()` and `exec()`, which drastically limits the usefulness of child setup functions.

In particular, it is not safe to call any function which may call `malloc()`, which includes POSIX functions such as `setenv()`. If you need to set up the child environment differently from the parent, you should use `g_get_environ()`, `g_environ_setenv()`, and `g_environ_unsetenv()`, and then pass the complete environment list to the `g_spawn...` function.

#### Parameters

user_data | user data to pass to the function. |

### g_spawn_async_with_pipes ()

    gboolean
    g_spawn_async_with_pipes (const gchar *working_directory,
                              gchar **argv,
                              gchar **envp,
                              GSpawnFlags flags,
                              GSpawnChildSetupFunc child_setup,
                              gpointer user_data,
                              GPid *child_pid,
                              gint *standard_input,
                              gint *standard_output,
                              gint *standard_error,
                              GError **error);

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 `g_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, `g_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 `g_spawn_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 `g_spawn_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 `g_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 `g_spawn_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 `g_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.

`error` 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 G_SPAWN_ERROR 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 `g_spawn_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.

#### Parameters

working_directory | child's current working directory, or `NULL` to inherit parent's, in the GLib file name encoding. | [allow-none]
argv | child's argument vector, in the GLib file name encoding. | [array zero-terminated=1]
envp | child's environment, or `NULL` to inherit parent's, in the GLib file name encoding. | [array zero-terminated=1][allow-none]
flags | flags from GSpawnFlags |
child_setup | function to run in the child just before `exec()`. | [scope async][allow-none]
user_data | user data for `child_setup` . | [closure]
child_pid | return location for child process ID, or `NULL`. | [out][allow-none]
standard_input | return location for file descriptor to write to child's stdin, or `NULL`. | [out][allow-none]
standard_output | return location for file descriptor to read child's stdout, or `NULL`. | [out][allow-none]
standard_error | return location for file descriptor to read child's stderr, or `NULL`. | [out][allow-none]
error | return location for error |

#### Returns

`TRUE` on success, `FALSE` if an error was set

### g_spawn_async ()

    gboolean
    g_spawn_async (const gchar *working_directory,
                   gchar **argv,
                   gchar **envp,
                   GSpawnFlags flags,
                   GSpawnChildSetupFunc child_setup,
                   gpointer user_data,
                   GPid *child_pid,
                   GError **error);

See `g_spawn_async_with_pipes()` for a full description; this function simply calls the `g_spawn_async_with_pipes()` without any pipes.

You should call `g_spawn_close_pid()` on the returned child process reference when you don't need it any more.

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()` instead to ensure that the spawned program opens its windows on the right screen.

Note that the returned `child_pid` on Windows is a handle to the child process and not its identifier. Process handles and process identifiers are different concepts on Windows.

#### Parameters

working_directory | child's current working directory, or `NULL` to inherit parent's. | [allow-none]
argv | child's argument vector. | [array zero-terminated=1]
envp | child's environment, or `NULL` to inherit parent's. | [array zero-terminated=1][allow-none]
flags | flags from GSpawnFlags |
child_setup | function to run in the child just before `exec()`. | [scope async][allow-none]
user_data | user data for `child_setup` . | [closure]
child_pid | return location for child process reference, or `NULL`. | [out][allow-none]
error | return location for error |

#### Returns

`TRUE` on success, `FALSE` if error is set

### g_spawn_sync ()

    gboolean
    g_spawn_sync (const gchar *working_directory,
                  gchar **argv,
                  gchar **envp,
                  GSpawnFlags flags,
                  GSpawnChildSetupFunc child_setup,
                  gpointer user_data,
                  gchar **standard_output,
                  gchar **standard_error,
                  gint *exit_status,
                  GError **error);

Executes a child synchronously (waits for the child to exit before returning). All output from the child is stored in `standard_output` and `standard_error` , if those parameters are non-`NULL`. Note that you must set the `G_SPAWN_STDOUT_TO_DEV_NULL` and `G_SPAWN_STDERR_TO_DEV_NULL` flags when passing `NULL` for `standard_output` and `standard_error` .

If `exit_status` is non-`NULL`, the platform-specific exit status of the child is stored there; see the documentation of `g_spawn_check_exit_status()` for how to use and interpret this. Note that it is invalid to pass `G_SPAWN_DO_NOT_REAP_CHILD` in `flags` .

If an error occurs, no data is returned in `standard_output` , `standard_error` , or `exit_status` .

This function calls `g_spawn_async_with_pipes()` internally; see that function for full details on the other parameters and details on how these functions work on Windows.

#### Parameters

working_directory | child's current working directory, or `NULL` to inherit parent's. | [allow-none]
argv | child's argument vector. | [array zero-terminated=1]
envp | child's environment, or `NULL` to inherit parent's. | [array zero-terminated=1][allow-none]
flags | flags from GSpawnFlags |
child_setup | function to run in the child just before `exec()`. | [scope async][allow-none]
user_data | user data for `child_setup` . | [closure]
standard_output | return location for child output, or `NULL`. | [out][array zero-terminated=1][element-type guint8][allow-none]
standard_error | return location for child error messages, or `NULL`. | [out][array zero-terminated=1][element-type guint8][allow-none]
exit_status | return location for child exit status, as returned by `waitpid()`, or `NULL`. | [out][allow-none]
error | return location for error, or `NULL` |

#### Returns

`TRUE` on success, `FALSE` if an error was set

### g_spawn_check_exit_status ()

    gboolean
    g_spawn_check_exit_status (gint exit_status,
                               GError **error);

Set `error` if `exit_status` indicates the child exited abnormally (e.g. with a nonzero exit code, or via a fatal signal).

The `g_spawn_sync()` and `g_child_watch_add()` family of APIs return an exit status for subprocesses encoded in a platform-specific way. On Unix, this is guaranteed to be in the same format `waitpid()` returns, and on Windows it is guaranteed to be the result of `GetExitCodeProcess()`.

Prior to the introduction of this function in GLib 2.34, interpreting `exit_status` required use of platform-specific APIs, which is problematic for software using GLib as a cross-platform layer.

Additionally, many programs simply want to determine whether or not the child exited successfully, and either propagate a GError or print a message to standard error. In that common case, this function can be used. Note that the error message in `error` will contain human-readable information about the exit status.

The `domain` and `code` of `error` have special semantics in the case where the process has an "exit code", as opposed to being killed by a signal. On Unix, this happens if `WIFEXITED()` would be true of `exit_status` . On Windows, it is always the case.

The special semantics are that the actual exit code will be the code set in `error` , and the domain will be `G_SPAWN_EXIT_ERROR`. This allows you to differentiate between different exit codes.

If the process was terminated by some means other than an exit status, the domain will be `G_SPAWN_ERROR`, and the code will be `G_SPAWN_ERROR_FAILED`.

This function just offers convenience; you can of course also check the available platform via a macro such as `G_OS_UNIX`, and use `WIFEXITED()` and `WEXITSTATUS()` on `exit_status` directly. Do not attempt to scan or parse the error message string; it may be translated and/or change in future versions of GLib.

#### Parameters

exit_status | An exit code as returned from `g_spawn_sync()` |
error | a GError |

#### Returns

`TRUE` if child exited successfully, `FALSE` otherwise (and `error` will be set)

Since 2.34

### g_spawn_command_line_async ()

    gboolean
    g_spawn_command_line_async (const gchar *command_line,
                                GError **error);

A simple version of `g_spawn_async()` that parses a command line with `g_shell_parse_argv()` and passes it to `g_spawn_async()`. Runs a command line in the background. Unlike `g_spawn_async()`, the `G_SPAWN_SEARCH_PATH` flag is enabled, other flags are not. Note that `G_SPAWN_SEARCH_PATH` can have security implications, so consider using `g_spawn_async()` directly if appropriate. Possible errors are those from `g_shell_parse_argv()` and `g_spawn_async()`.

The same concerns on Windows apply as for `g_spawn_command_line_sync()`.

#### Parameters

command_line | a command line |
error | return location for errors |

#### Returns

`TRUE` on success, `FALSE` if error is set

### g_spawn_command_line_sync ()

    gboolean
    g_spawn_command_line_sync (const gchar *command_line,
                               gchar **standard_output,
                               gchar **standard_error,
                               gint *exit_status,
                               GError **error);

A simple version of `g_spawn_sync()` with little-used parameters removed, taking a command line instead of an argument vector. See `g_spawn_sync()` for full details. `command_line` will be parsed by `g_shell_parse_argv()`. Unlike `g_spawn_sync()`, the `G_SPAWN_SEARCH_PATH` flag is enabled. Note that `G_SPAWN_SEARCH_PATH` can have security implications, so consider using `g_spawn_sync()` directly if appropriate. Possible errors are those from `g_spawn_sync()` and those from `g_shell_parse_argv()`.

If `exit_status` is non-`NULL`, the platform-specific exit status of the child is stored there; see the documentation of `g_spawn_check_exit_status()` for how to use and interpret this.

On Windows, please note the implications of `g_shell_parse_argv()` parsing `command_line` . Parsing is done according to Unix shell rules, not Windows command interpreter rules. Space is a separator, and backslashes are special. Thus you cannot simply pass a `command_line` containing canonical Windows paths, like "c:\program files\app\app.exe", as the backslashes will be eaten, and the space will act as a separator. You need to enclose such paths with single quotes, like "'c:\program files\app\app.exe' 'e:\folder\argument.txt'".

#### Parameters

command_line | a command line |
standard_output | return location for child output. | [out][array zero-terminated=1][element-type guint8][allow-none]
standard_error | return location for child errors. | [out][array zero-terminated=1][element-type guint8][allow-none]
exit_status | return location for child exit status, as returned by `waitpid()`. | [out][allow-none]
error | return location for errors |

#### Returns

`TRUE` on success, `FALSE` if an error was set

### g_spawn_close_pid ()

    void
    g_spawn_close_pid (GPid pid);

On some platforms, notably Windows, the GPid type represents a resource which must be closed to prevent resource leaking. `g_spawn_close_pid()` is provided for this purpose. It should be used on all platforms, even though it doesn't do anything under UNIX.

#### Parameters

pid | The process reference to close |

## Types and Values

### enum GSpawnError

Error codes returned by spawning processes.

#### Members

G_SPAWN_ERROR_FORK | Fork failed due to lack of memory. |
G_SPAWN_ERROR_READ | Read or select on pipes failed. |
G_SPAWN_ERROR_CHDIR | Changing to working directory failed. |
G_SPAWN_ERROR_ACCES | execv() returned `EACCES` |
G_SPAWN_ERROR_PERM | execv() returned `EPERM` |
G_SPAWN_ERROR_TOO_BIG | execv() returned `E2BIG` |
G_SPAWN_ERROR_2BIG | deprecated alias for `G_SPAWN_ERROR_TOO_BIG` |
G_SPAWN_ERROR_NOEXEC | execv() returned `ENOEXEC` |
G_SPAWN_ERROR_NAMETOOLONG | execv() returned `ENAMETOOLONG` |
G_SPAWN_ERROR_NOENT | execv() returned `ENOENT` |
G_SPAWN_ERROR_NOMEM | execv() returned `ENOMEM` |
G_SPAWN_ERROR_NOTDIR | execv() returned `ENOTDIR` |
G_SPAWN_ERROR_LOOP | execv() returned `ELOOP` |
G_SPAWN_ERROR_TXTBUSY | execv() returned `ETXTBUSY` |
G_SPAWN_ERROR_IO | execv() returned `EIO` |
G_SPAWN_ERROR_NFILE | execv() returned `ENFILE` |
G_SPAWN_ERROR_MFILE | execv() returned `EMFILE` |
G_SPAWN_ERROR_INVAL | execv() returned `EINVAL` |
G_SPAWN_ERROR_ISDIR | execv() returned `EISDIR` |
G_SPAWN_ERROR_LIBBAD | execv() returned `ELIBBAD` |
G_SPAWN_ERROR_FAILED | Some other fatal failure, `error->message` should explain. |

### G_SPAWN_ERROR

    #define G_SPAWN_ERROR g_spawn_error_quark ()

Error domain for spawning processes. Errors in this domain will be from the GSpawnError enumeration. See GError for information on error domains.

### enum GSpawnFlags

Flags passed to `g_spawn_sync()`, `g_spawn_async()` and `g_spawn_async_with_pipes()`.

#### Members

G_SPAWN_DEFAULT | no flags, default behaviour |
G_SPAWN_LEAVE_DESCRIPTORS_OPEN | the parent's open file descriptors will be inherited by the child; otherwise all descriptors except stdin, stdout and stderr will be closed before calling `exec()` in the child. |
G_SPAWN_DO_NOT_REAP_CHILD | the child will not be automatically reaped; you must use `g_child_watch_add()` yourself (or call `waitpid()` or handle `SIGCHLD` yourself), or the child will become a zombie. |
G_SPAWN_SEARCH_PATH | `argv[0]` need not be an absolute path, it will be looked for in the user's `PATH`. |
G_SPAWN_STDOUT_TO_DEV_NULL | the child's standard output will be discarded, instead of going to the same location as the parent's standard output. |
G_SPAWN_STDERR_TO_DEV_NULL | the child's standard error will be discarded. |
G_SPAWN_CHILD_INHERITS_STDIN | the child will inherit the parent's standard input (by default, the child's standard input is attached to `/dev/null`). |
G_SPAWN_FILE_AND_ARGV_ZERO | 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 `g_spawn_async_with_pipes()` uses `argv[0]` as the file to execute, and passes all of `argv` to the child. |
G_SPAWN_SEARCH_PATH_FROM_ENVP | if `argv[0]` is not an abolute path, it will be looked for in the `PATH` from the passed child environment. Since: 2.34 |
G_SPAWN_CLOEXEC_PIPES | create all pipes with the `O_CLOEXEC` flag set. Since: 2.40 |

### G_SPAWN_EXIT_ERROR

    #define G_SPAWN_EXIT_ERROR g_spawn_exit_error_quark ()

Error domain used by `g_spawn_check_exit_status()`. The code will be the program exit code.