git/run-command.h

#ifndef RUN_COMMAND_H
#define RUN_COMMAND_H

#include "thread-utils.h"

#include "strvec.h"

/**
 * The run-command API offers a versatile tool to run sub-processes with
 * redirected input and output as well as with a modified environment
 * and an alternate current directory.
 *
 * A similar API offers the capability to run a function asynchronously,
 * which is primarily used to capture the output that the function
 * produces in the caller in order to process it.
 */


/**
 * This describes the arguments, redirections, and environment of a
 * command to run in a sub-process.
 *
 * The caller:
 *
 * 1. allocates and clears (using child_process_init() or
 *    CHILD_PROCESS_INIT) a struct child_process variable;
 * 2. initializes the members;
 * 3. calls start_command();
 * 4. processes the data;
 * 5. closes file descriptors (if necessary; see below);
 * 6. calls finish_command().
 *
 * Special forms of redirection are available by setting these members
 * to 1:
 *
 *  .no_stdin, .no_stdout, .no_stderr: The respective channel is
 *		redirected to /dev/null.
 *
 *	.stdout_to_stderr: stdout of the child is redirected to its
 *		stderr. This happens after stderr is itself redirected.
 *		So stdout will follow stderr to wherever it is
 *		redirected.
 */
struct child_process {};

#define CHILD_PROCESS_INIT

/**
 * The functions: start_command, finish_command, run_command do the following:
 *
 * - If a system call failed, errno is set and -1 is returned. A diagnostic
 *   is printed.
 *
 * - If the program was not found, then -1 is returned and errno is set to
 *   ENOENT; a diagnostic is printed only if .silent_exec_failure is 0.
 *
 * - Otherwise, the program is run. If it terminates regularly, its exit
 *   code is returned. No diagnostic is printed, even if the exit code is
 *   non-zero.
 *
 * - If the program terminated due to a signal, then the return value is the
 *   signal number + 128, ie. the same value that a POSIX shell's $? would
 *   report.  A diagnostic is printed.
 *
 */

/**
 * Initialize a struct child_process variable.
 */
void child_process_init(struct child_process *);

/**
 * Release the memory associated with the struct child_process.
 * Most users of the run-command API don't need to call this
 * function explicitly because `start_command` invokes it on
 * failure and `finish_command` calls it automatically already.
 */
void child_process_clear(struct child_process *);

int is_executable(const char *name);

/**
 * Check if the command exists on $PATH. This emulates the path search that
 * execvp would perform, without actually executing the command so it
 * can be used before fork() to prepare to run a command using
 * execve() or after execvp() to diagnose why it failed.
 *
 * The caller should ensure that command contains no directory separators.
 *
 * Returns 1 if it is found in $PATH or 0 if the command could not be found.
 */
int exists_in_PATH(const char *command);

/**
 * Return the path that is used to execute Unix shell command-lines.
 */
char *git_shell_path(void);

/**
 * Start a sub-process. Takes a pointer to a `struct child_process`
 * that specifies the details and returns pipe FDs (if requested).
 * See below for details.
 */
int start_command(struct child_process *);

/**
 * Wait for the completion of a sub-process that was started with
 * start_command().
 */
int finish_command(struct child_process *);

int finish_command_in_signal(struct child_process *);

/**
 * A convenience function that encapsulates a sequence of
 * start_command() followed by finish_command(). Takes a pointer
 * to a `struct child_process` that specifies the details.
 */
int run_command(struct child_process *);

/*
 * Prepare a `struct child_process` to run auto-maintenance. Returns 1 if the
 * process has been prepared and is ready to run, or 0 in case auto-maintenance
 * should be skipped.
 */
int prepare_auto_maintenance(int quiet, struct child_process *maint);

/*
 * Trigger an auto-gc
 */
int run_auto_maintenance(int quiet);

/**
 * Execute the given command, sending "in" to its stdin, and capturing its
 * stdout and stderr in the "out" and "err" strbufs. Any of the three may
 * be NULL to skip processing.
 *
 * Returns -1 if starting the command fails or reading fails, and otherwise
 * returns the exit code of the command. Any output collected in the
 * buffers is kept even if the command returns a non-zero exit. The hint fields
 * gives starting sizes for the strbuf allocations.
 *
 * The fields of "cmd" should be set up as they would for a normal run_command
 * invocation. But note that there is no need to set the in, out, or err
 * fields; pipe_command handles that automatically.
 */
int pipe_command(struct child_process *cmd,
		 const char *in, size_t in_len,
		 struct strbuf *out, size_t out_hint,
		 struct strbuf *err, size_t err_hint);

/**
 * Convenience wrapper around pipe_command for the common case
 * of capturing only stdout.
 */
static inline int capture_command(struct child_process *cmd,
				  struct strbuf *out,
				  size_t hint)
{}

/*
 * The purpose of the following functions is to feed a pipe by running
 * a function asynchronously and providing output that the caller reads.
 *
 * It is expected that no synchronization and mutual exclusion between
 * the caller and the feed function is necessary so that the function
 * can run in a thread without interfering with the caller.
 *
 * The caller:
 *
 * 1. allocates and clears (memset(&asy, 0, sizeof(asy));) a
 *    struct async variable;
 * 2. initializes .proc and .data;
 * 3. calls start_async();
 * 4. processes communicates with proc through .in and .out;
 * 5. closes .in and .out;
 * 6. calls finish_async().
 *
 * There are serious restrictions on what the asynchronous function can do
 * because this facility is implemented by a thread in the same address
 * space on most platforms (when pthreads is available), but by a pipe to
 * a forked process otherwise:
 *
 * - It cannot change the program's state (global variables, environment,
 *   etc.) in a way that the caller notices; in other words, .in and .out
 *   are the only communication channels to the caller.
 *
 * - It must not change the program's state that the caller of the
 *   facility also uses.
 *
 */
struct async {};

/**
 * Run a function asynchronously. Takes a pointer to a `struct
 * async` that specifies the details and returns a set of pipe FDs
 * for communication with the function. See below for details.
 */
int start_async(struct async *async);

/**
 * Wait for the completion of an asynchronous function that was
 * started with start_async().
 */
int finish_async(struct async *async);

int in_async(void);
int async_with_fork(void);
void check_pipe(int err);

/**
 * This callback should initialize the child process and preload the
 * error channel if desired. The preloading of is useful if you want to
 * have a message printed directly before the output of the child process.
 * pp_cb is the callback cookie as passed to run_processes_parallel.
 * You can store a child process specific callback cookie in pp_task_cb.
 *
 * See run_processes_parallel() below for a discussion of the "struct
 * strbuf *out" parameter.
 *
 * Even after returning 0 to indicate that there are no more processes,
 * this function will be called again until there are no more running
 * child processes.
 *
 * Return 1 if the next child is ready to run.
 * Return 0 if there are currently no more tasks to be processed.
 * To send a signal to other child processes for abortion,
 * return the negative signal number.
 */
get_next_task_fn;

/**
 * This callback is called whenever there are problems starting
 * a new process.
 *
 * See run_processes_parallel() below for a discussion of the "struct
 * strbuf *out" parameter.
 *
 * pp_cb is the callback cookie as passed into run_processes_parallel,
 * pp_task_cb is the callback cookie as passed into get_next_task_fn.
 *
 * Return 0 to continue the parallel processing. To abort return non zero.
 * To send a signal to other child processes for abortion, return
 * the negative signal number.
 */
start_failure_fn;

/**
 * This callback is called on every child process that finished processing.
 *
 * See run_processes_parallel() below for a discussion of the "struct
 * strbuf *out" parameter.
 *
 * pp_cb is the callback cookie as passed into run_processes_parallel,
 * pp_task_cb is the callback cookie as passed into get_next_task_fn.
 *
 * Return 0 to continue the parallel processing.  To abort return non zero.
 * To send a signal to other child processes for abortion, return
 * the negative signal number.
 */
task_finished_fn;

/**
 * Option used by run_processes_parallel(), { 0 }-initialized means no
 * options.
 */
struct run_process_parallel_opts
{};

/**
 * Options are passed via the "struct run_process_parallel_opts" above.
 *
 * Runs N 'processes' at the same time. Whenever a process can be
 * started, the callback opts.get_next_task is called to obtain the data
 * required to start another child process.
 *
 * The children started via this function run in parallel. Their output
 * (both stdout and stderr) is routed to stderr in a manner that output
 * from different tasks does not interleave (but see "ungroup" below).
 *
 * If the "ungroup" option isn't specified, the API will set the
 * "stdout_to_stderr" parameter in "struct child_process" and provide
 * the callbacks with a "struct strbuf *out" parameter to write output
 * to. In this case the callbacks must not write to stdout or
 * stderr as such output will mess up the output of the other parallel
 * processes. If "ungroup" option is specified callbacks will get a
 * NULL "struct strbuf *out" parameter, and are responsible for
 * emitting their own output, including dealing with any race
 * conditions due to writing in parallel to stdout and stderr.
 */
void run_processes_parallel(const struct run_process_parallel_opts *opts);

/**
 * Convenience function which prepares env for a command to be run in a
 * new repo. This adds all GIT_* environment variables to env with the
 * exception of GIT_CONFIG_PARAMETERS and GIT_CONFIG_COUNT (which cause the
 * corresponding environment variables to be unset in the subprocess) and adds
 * an environment variable pointing to new_git_dir. See local_repo_env in
 * environment.h for more information.
 */
void prepare_other_repo_env(struct strvec *env, const char *new_git_dir);

/**
 * Possible return values for start_bg_command().
 */
enum start_bg_result {};

/**
 * Callback used by start_bg_command() to ask whether the
 * child process is ready or needs more time to become "ready".
 *
 * The callback will receive the cmd and cb_data arguments given to
 * start_bg_command().
 *
 * Returns 1 is child needs more time (subject to the requested timeout).
 * Returns 0 if child is "ready".
 * Returns -1 on any error and cause start_bg_command() to also error out.
 */
start_bg_wait_cb;

/**
 * Start a command in the background.  Wait long enough for the child
 * to become "ready" (as defined by the provided callback).  Capture
 * immediate errors (like failure to start) and any immediate exit
 * status (such as a shutdown/signal before the child became "ready")
 * and return this like start_command().
 *
 * We run a custom wait loop using the provided callback to wait for
 * the child to start and become "ready".  This is limited by the given
 * timeout value.
 *
 * If the child does successfully start and become "ready", we orphan
 * it into the background.
 *
 * The caller must not call finish_command().
 *
 * The opaque cb_data argument will be forwarded to the callback for
 * any instance data that it might require.  This may be NULL.
 */
enum start_bg_result start_bg_command(struct child_process *cmd,
				      start_bg_wait_cb *wait_cb,
				      void *cb_data,
				      unsigned int timeout_sec);

int sane_execvp(const char *file, char *const argv[]);

#endif