> One thing I don't like too much with the current patch is that it doesn't respect the output order.
> The DPUTS messages appear in between other messages, presumably in the order they were found in the output.
> I'm wondering whether tackling this ordering issue would be worth the added complexity.
This is probably happening because the PTY output is being buffered --
I suspect in the case where they are grouped together it's not
line-buffered and where they are separated it is line-buffered, though
what you may have done to change it I don't immediately see.
The comptest function is the only piece of code in the comptest file that prints substantial parts of the output retrieved from zpty. It checks the output against a number of patterns. If it matches one of them it prints a corresponding message, removes the recognized part from the output and starts again until nothing recognizable is left. In my first attempt, I added one more pattern that recognizes DPUTS messages. Thus, these appear in the right order with respect to other recognized messages.
The proposed patch is much more general. Whenever output is read from zpty, it's immediately checked for DPUTS messages. If any are found, they are printed and removed from the saved output. The remaining output then goes through the normal processing. Thus, DPUTS messages will always show up before any messages produced by the normal processing.
It's probably more helpful to have the DPUTS output appear adjacent to
the input that triggered it, even though strictly speaking DPUTS
should be treated like stderr rather than like "normal" test output.
You could experiment with having zpty_handle_dputs use "print -u2".
Yeah, that would be an option. Then the ordering question becomes moot. Arguably it would also avoid any confusion. Since stderr and stdout are separate streams handled separately by the test runner, nobody will have ordering expectations.
I guess that's the way to go if nobody thinks the ordering is that important.
Philippe