it is obvious that, in the general case, managing multiple streams on multiple filehandles using existing technologies is a *hard* problem. it does, however (and thanks for the hint barrie) seem possible to solve the problem for special cases--those you can control.
On 9/22/06, Barrie Slaymaker <[EMAIL PROTECTED]> wrote:
If you can patch the source process' program, you can try disabling buffering and having it tag each chunk of output to a single stream, or having it wait for "user" (i.e. parent process) input after each significant bit of output are two decent approaches.
first of all, i think this is calling for a TAP Emitter (TAPx::Emitter?), which new harnesses can use to emit TAP. if there's an emitter that plays friendly with TAPx::Parser, especially in the case of streamed TAP (TAPx::Emitter::Streams?) using one of the methods barrie suggests, or some other equally solid approach, you will have solved the problem for some subset of the problem space. although it is not your final goal, (work everywhere perfectly now) it does achieve some subgoals, and it is a direction to move forward. open the door for others to use your shiny new TAP parser in the way they want by providing a means to do so. there's no denying it will be seen as a Good Thing. ~jerry
