summaryrefslogtreecommitdiff
path: root/run-command.h
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2016-06-17 23:38:47 (GMT)
committerJunio C Hamano <gitster@pobox.com>2016-06-18 00:03:56 (GMT)
commit96335bcf4d64c29add3692fb41671190123cf44e (patch)
tree079533fb3d349577395d95f0047e13a73f9b70a4 /run-command.h
parent4322353bfb53a83e6657af50603d3521ee9d7d0c (diff)
downloadgit-96335bcf4d64c29add3692fb41671190123cf44e.zip
git-96335bcf4d64c29add3692fb41671190123cf44e.tar.gz
git-96335bcf4d64c29add3692fb41671190123cf44e.tar.bz2
run-command: add pipe_command helper
We already have capture_command(), which captures the stdout of a command in a way that avoids deadlocks. But sometimes we need to do more I/O, like capturing stderr as well, or sending data to stdin. It's easy to write code that deadlocks racily in these situations depending on how fast the command reads its input, or in which order it writes its output. Let's give callers an easy interface for doing this the right way, similar to what capture_command() did for the simple case. The whole thing is backed by a generic poll() loop that can feed an arbitrary number of buffers to descriptors, and fill an arbitrary number of strbufs from other descriptors. This seems like overkill, but the resulting code is actually a bit cleaner than just handling the three descriptors (because the output code for stdout/stderr is effectively duplicated, so being able to loop is a benefit). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'run-command.h')
-rw-r--r--run-command.h31
1 files changed, 24 insertions, 7 deletions
diff --git a/run-command.h b/run-command.h
index 11f76b0..5066649 100644
--- a/run-command.h
+++ b/run-command.h
@@ -79,17 +79,34 @@ int run_command_v_opt(const char **argv, int opt);
int run_command_v_opt_cd_env(const char **argv, int opt, const char *dir, const char *const *env);
/**
- * Execute the given command, capturing its stdout in the given strbuf.
+ * 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. The output collected in the
- * buffer is kept even if the command returns a non-zero exit. The hint field
- * gives a starting size for the strbuf allocation.
+ * 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 cmd->out; the function
- * sets it up for the caller.
+ * 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.
*/
-int capture_command(struct child_process *cmd, struct strbuf *buf, size_t hint);
+static inline int capture_command(struct child_process *cmd,
+ struct strbuf *out,
+ size_t hint)
+{
+ return pipe_command(cmd, NULL, 0, out, hint, NULL, 0);
+}
/*
* The purpose of the following functions is to feed a pipe by running