This seems to be hard enough that even Debian's annotate-output doesn't do it.

Contrarily to what you claim, Zsh also fails to preserve the order in both.txt, as my tests confirmed. From https://zsh.sourceforge.io/Doc/Release/Redirection.html, "the shell opens the file descriptor as a pipe to a process that copies its input to all the specified outputs, similar to tee, provided the MULTIOS option is set, as it is by default". So the race condition is present.

I think you are out of luck here.

Aww, I didn't notice the order issue with Zsh; I just did a quick test to see if I had the syntax correct so I could copy/paste the same thing and try it in BASH and see if it worked; it wasn't until I had your solution that I got hopeful enough to actually write a little wrapper around it to really test the output. :)

Dang; well, again, thanks for looking into it!

Wait; your answer does give me an idea, though. Our systems are mostly CentOS so annotate-output might not be an option per se, but maybe I can rig something up based on what you've provided that pipes all the different outputs through a filter (awk, or something) that adds timestamps.

The goal is simply to be able to reconstruct the order of output lines, regardless of whether they came from stdout or stderr; if each line has a prepended timestamp, then even if the original output file has them out of order I can just sort the file. I just assumed it was a given that the shell would have to take care of that interleaving but perhaps, as The Dude might say, my thinking has gotten too uptight.

Of course, this solution might get a bit unfortunate for scripts that generate truly copious output, but for the common case I bet it'd be fine and even in those cases it should still work, even if managing the output files is a little more time-consuming.

I'm afraid even that is not reliable either.

Something like cmd 2> >(timestamp_err) > >(timestamp_out) will inevitably cause a race condition since there are still two concurrent processes.

It is not impossible that, in practice, the order of magnitude of the "average delay" between input received and output written by the time stamping programs is much smaller than the average rate of output of cmd. But it is not something to be relied upon anyway...