Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Don't buffer stderr of --filter #2729
When calling external filter programs, e.g.
Once the program has finished executing,
This buffering (waiting until the filter has finished before showing anything on stderr) can make debugging filters tedious. For example, if a filter takes a long time to run (e.g. it's doing a lot of IO), then we would like to be notified of any problems without having to wait for the whole thing to finish. Likewise, if there is a bug in a filter which is transforming a large number of elements, we have to wait until all of them have failed, and look through the whole output of all failures, rather than being able to spot the error immediately after the first failure.
In particular, I use a Pandoc filter called "panpipe" which allows arbitrary shell commands to be executed ( http://chriswarbo.net/git/panpipe/branches/master/ , described in more detail at http://chriswarbo.net/essays/activecode ), and use it to run many resource-intensive scripts. To avoid having to wait for stderr, I must use
It looks like the only other user of the
Perhaps a simpler and neater solution would be passing the
If this sounds reasonable, I may take a stab at implementing it.
It's not as simple as I thought. The PDF reader doesn't simply print stderr output (or discard it). It analyzes the log messages in order to present to the pandoc user just the relevant part, without the full output, which can be confusing.
So probably the best approach is to offer an alternative version of pipeProcess (say, pipeProcessStreamingStderr) that streams stderr instead of returning it.