Allow real-time streaming of stdout and stderr

[4O4-Not-F0und]

Hi, I'm currently working with this lib and I've found a problem that, the Command.Run buffers all output from the process and makes it available only after the command completes. This prevents applications from accessing the output stream in real-time, which is essential for real-time logging.

I propose adding a mechanism to stream stdout and stderr to custom destinations. My proposed changes are as follows:

1. Add stdout and stderr io.Writer fields to the Command struct.
2. Expose public methods, SetStdout(io.Writer) and SetStderr(io.Writer), to allow configuration for custom writers.
3. Inside the runWithResult method, use io.MultiWriter to direct the process output to multiple destinations.

diff --git a/command.go b/command.go
index df231d5..e14f398 100644
--- a/command.go
+++ b/command.go
@@ -7,6 +7,7 @@ package ytdlp
 import (
        "context"
        "fmt"
+       "io"
        "maps"
        "os"
        "os/exec"
@@ -39,6 +40,11 @@ type Command struct {
        disableEnvVarInherit bool
 
        progress *progressHandler
+
+       // stdout is an optional writer to write the command's stdout to in real-time.
+       stdout io.Writer
+       // stderr is an optional writer to write the command's stderr to in real-time.
+       stderr io.Writer
 }
 
 // Clone returns a copy of the command, with all flags, env vars, executable,
@@ -52,6 +58,8 @@ func (c *Command) Clone() *Command {
                flagConfig:           c.flagConfig.Clone(),
                separateProcessGroup: c.separateProcessGroup,
                progress:             c.progress,
+               stdout:               c.stdout,
+               stderr:               c.stderr,
        }
        maps.Copy(cc.env, c.env)
        c.mu.RUnlock()
@@ -137,6 +145,22 @@ func (c *Command) SetEnvVarInherit(enabled bool) *Command {
        return c
 }
 
+// SetStdout sets an optional writer to write the command's stdout to in real-time.
+func (c *Command) SetStdout(stdout io.Writer) *Command {
+       c.mu.Lock()
+       c.stdout = stdout
+       c.mu.Unlock()
+       return c
+}
+
+// SetStderr sets an optional writer to write the command's stderr to in real-time.
+func (c *Command) SetStderr(stderr io.Writer) *Command {
+       c.mu.Lock()
+       c.stderr = stderr
+       c.mu.Unlock()
+       return c
+}
+
 func (c *Command) hasJSONFlag() bool {
        if slices.Contains(c.flagConfig.VerbositySimulation.Print, "%(j)") && len(c.flagConfig.VerbositySimulation.Print) == 1 {
                return true
@@ -278,7 +302,14 @@ func (c *Command) runWithResult(ctx context.Context, cmd *exec.Cmd) (*Result, er
        }
 
        cmd.Stdout = stdout
+       if c.stdout != nil {
+               cmd.Stdout = io.MultiWriter(c.stdout, stdout)
+       }
+
        cmd.Stderr = stderr
+       if c.stderr != nil {
+               cmd.Stderr = io.MultiWriter(c.stderr, stderr)
+       }
 
        applySyscall(cmd, c.separateProcessGroup)

This change provides greater flexibility and real-time interactivity. I'm opening this discussion to discuss the solution.

[lrstanley]

See some of my concerns with supporting this here: #59 (comment)

The tl;dr is that, even if I were to support it, it likely wouldn't be through a multi-writer, because this would actually break stdout/stderr which is currently used for other purposes, depending on what the user passes in to other arguments (e.g. streaming of data to stdout through - which forces all regular output to stderr, would break all progress, json, error info, etc) and would also change what a user expected to get back from that multi-writer. The actual implementation would likely be a bit more complex, where I allow the actual stdout and stderr to do different things, but I treat the stdout/stderr that a user passes in to by dynamically written to based off what I receive (e.g. stderr content may actually get redirected to stdout through the method you described).

I am likely going to support it, but it's low on my priority list at the moment.

[4O4-Not-F0und]

Thanks for the detailed explanation. I understand the potential complexities and appreciate you sharing your thoughts.

To keep things organized, shall I open a new feature issue to track this?