Something as simple as reading the stdout from a command
turns out to be rather hard to do right. Doing:
if (!run_command(cmd))
strbuf_read(buf, cmd.out, 0);
can result in deadlock if the child process produces a large
amount of output. What happens is:
1. The parent spawns the
On Sun, Mar 22, 2015 at 6:07 AM, Jeff King p...@peff.net wrote:
Something as simple as reading the stdout from a command
turns out to be rather hard to do right. Doing:
if (!run_command(cmd))
strbuf_read(buf, cmd.out, 0);
can result in deadlock if the child process produces a
Eric Sunshine sunsh...@sunshineco.com writes:
On Sun, Mar 22, 2015 at 6:07 AM, Jeff King p...@peff.net wrote:
Something as simple as reading the stdout from a command
turns out to be rather hard to do right. Doing:
if (!run_command(cmd))
strbuf_read(buf, cmd.out, 0);
can result
Junio C Hamano gits...@pobox.com writes:
Eric Sunshine sunsh...@sunshineco.com writes:
It does feel like a layering violation. If moved to the run-command
API, it could given one of the following names or something better:
run_command_capture()
capture_command()
Jeff King p...@peff.net writes:
diff --git a/strbuf.h b/strbuf.h
index 1883494..93a50da 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -1,6 +1,8 @@
#ifndef STRBUF_H
#define STRBUF_H
+struct child_process;
+
/**
* strbuf's are meant to be used with all the usual C string and memory
On Sun, Mar 22, 2015 at 04:22:50PM -0700, Junio C Hamano wrote:
+/**
* Read a line from a FILE *, overwriting the existing contents
* of the strbuf. The second argument specifies the line
* terminator character, typically `'\n'`.
It is an unfortunate tangent that this is a bugfix
On Sun, Mar 22, 2015 at 03:36:01PM -0400, Eric Sunshine wrote:
This is really at the intersection of the strbuf and
run-command APIs, so you could argue for it being part of
either It is logically quite like the strbuf_read_file()
function, so I put it there.
It does feel like a
7 matches
Mail list logo
